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ABSTKACT 


This  thesis  gives  the  specifications  of  a  simulation 
model  for  a  particular  Local  Area  Network  (LAN)  system 
which  implements  functions  of  the  Stock  Point  Logistics 
Integrated  Communications  Environment  (SPLICE) .  First, 
system  simulation  and  LAN  components  euid  performance  measures 
are  discussed  in  general.  Then,  the  components  of  a  LAN 
system  model  employing  bus  architecture  are  identified  and 
modeled  as  an  open  network  of  queues. 
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I .  INTRODUCTION 


A.  GENERAL 

Computer  networks  are  an  importemt  part  of  our  society 
and  directly  or  indirectly  affect  m^my  people.  In  recent 
years f  there  has  been  considerable  interest  in  studies 
related  to  a  special  kind  of  network,  the  Local  Area  Net¬ 
works  (LAN) ,  ^md  it  is  reasonable  to  expect  a  proliferation 
of  LANs  within  the  next  decade,  due  to  new  technologies 
and  potential  applications. 

One  major  attraction  of  LANs  is  that  they  make  possible 
the  economical  and  efficient  sharing  of  resources,  i.e., 
processors,  expensive  peripheral  devices,  databases,  communi¬ 
cations  bandwidth,  information,  etc.  Because  of  the  grow¬ 
ing  complexity  of  the  Navy's  logistics  functions,  the 
increase  in  the  nxunber  of  above  mentioned  resources,  and  the 
need  to  support  interactive  operations  at  the  Navy's  stock 
points  and  inventory  control  points,  have  led  the  developers 
of  the  Supply  Point  Logistics  Integrated  Commiinications 
Environment  (SPLICE) ,  to  employ  a  local  area  network  at  each 
site  for  integration  of  all  computer  resources  [Ref.  1]. 

Also  this  local  area  network  will  serve  as  the  basic  linkage 
for  future  system  integration  within  a  designated  location 
[Ref.  2].  That  is,  as  SPLICE  requirements  evolve  and  as 
technology  changes,  dissimilar  devices  e.g.,  new  host  computers 


mass  storage  devices,  teleprocessing  gateways,  can  be  added 
to  the  LAN  easily  without  having  to  redesign  other  parts  of 
the  SPLICE  system. 

The  SPLICE  project  at  the  Naval  Postgraduate  School  will 
produce  specifications  and  recommendations  for  the  design  of 
the  LAN  to  be  implemented  at  stock  points  and  inventory  con¬ 
trol  points.  During  the  design  phase  of  any  system  a  simula¬ 
tion  model  has  proven  to  be  an  effective  analytical  tool  to 
assist  in  the  decision  making  process.  Simulation  modeling, 
though  based  heavily  upon  computer  science,  mathematics,  proba¬ 
bility,  and  statistics,  remains  an  intuitive  process  [Ref.  3] . 
The  following  quotation  of  R.  E.  Shannon  [Ref.  3]  stresses 
a  note  of  warning  about  simulation:  "Like  all  powerful  tools 
which  depend  heavily  upon  art  in  their  application,  simulation 
is  capable  of  giving  either  very  good  or  very  bad  results, 
depending  upon  how  it  is  used.  It  can  either  enlighten  or 
mislead. "  This  thesis  covers  work  done  toward  the  develop¬ 
ment  of  such  an  effective  tool,  a  simulation  model  for  local 
area  networks  design. 

1.  Scope  of  Research 

Although  simulation  models  differ  significantly  in 
their  construction  and  use,  the  analysis  and  development  of 
all  types  consists  of  three  general  phases:  Conceptualiza¬ 
tion  (specifications) ,  implementation,  and  experimentation. 
Towards  the  development  of  a  complete  simulation  model  for  a 
local  area  network  implementing  the  SPLICE  functions,  this 


research  covers  the  conceptualization  phase  by  discussing 
the  specifications  of  such  a  model. 

2.  Approach 

The  development  of  specifications  of  the  LAN  simu~ 
lation  model  went  through  clearly  definable  but  overlapping 
and  frequently  iterative  steps.  A  brief  discussion  of  each 
step  taken  in  the  development  process  follows: 

a.  Study  system  simulation  in  general:  A  general  study 
of  system  simulation  was  conducted  for  the  purpose  of  ob~ 
taining  a  knowledge  of  general  system  simulation  and  select¬ 
ing  an  appropriate  simulation  technique  to  be  used  with  the 
LAN  simulation  model. 

b.  Study  LAN  components  and  performance  measures  in  general 
LAN  components  and  performance  measurements  were  investi¬ 
gated  in  order  to  develop  a  knowledge  and  understanding  of 
what  actually  composes  a  LAN  and  determine  the  different 
types  of  performance  measures  which  could  be  made  on  com¬ 
puter  networks  in  general.  Such  investigation  was  necessary 
for  the  development  of  an  accurate  LAN  simulation  model . 

c.  Giving  specifications  for  a  particular  LAN  simulation 
model:  This  third  step  in  the  development  process  was  con¬ 
cerned  with  the  detailed  design  of  a  LAN  simulation  model. 

That  is,  the  symbolic  (logical-mathematical)  description 

of  a  local  area  network  system  to  the  level  of  detail 
appropriate  to  give  a  valid  representation  of  the  system. 

d.  Study  model  implementation  and  experimentation:  This 
final  step  in  the  development  process,  though  not  within 
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the  scope  of  the  thesis,  was  conducted  in  order  to  obtain 
a  knowledge  of  these  two  important  phases  in  simulation 
model  construction.  This  knowledge  was  necessary  in  deter¬ 
mining  the  level  of  LAN  system  resolution  to  be  represented 
in  the  simulation  model. 

B .  OVERVIEW 

Following  the  steps  tedcen  in  the  development  process  of 
a  simulation  model,  this  thesis  discusses,  first,  in  Chapter 
II  the  development  of  a  system  simulation.  Next,  in  Chapter 
III,  are  discussions  of  the  various  components  which  make  up 
a  local  area  network  3uid  different  performance  measures  are  des¬ 
cribed.  Then,  in  Chapter  IV,  the  specifications  of  a  simulation  model 
for  a  local  area  network  are  given.  Finally,  Chapter  V  is 
concerned  with  the  implementation  and  experimentation  phases 
of  simulation  model  construction. 


II.  SYSTEM  SIMULATION 


One  of  the  most  important  and  useful  tools  for  euialyzing  the 
design  emd  operation  of  complex  processes  or  systems  is  simula¬ 
tion.  Simulation  is  a  very  wide-open  and  somewhat  not  well  de¬ 
fined  subject  of  great  importance  to  those  responsible  for  the 
design  of  systems  as  well  as  those  responsible  for  their  operation. 

In  general  usage,  simulation  is  defined  as  an  act  or 

process  that  gives  the  appearance  or  effect  of  some  part  of 

reality — a  counterfeit,  a  feigning  [Ref.  41.  Among  the  many 

definitions  offered  by  various  authors,  the  more  suitable 

for  the  purposes  of  this  thesis  is  given  by  Shannon  [Ref.  3]: 

Simulation  is  the  process  of  designing  a  model  of 
a  real  system  and  conducting  experiments  with  this 
model  for  the  purpose  either  of  understanding  the 
behavior  of  the  system  or  of  evaluating  various 
strategies  (within  the  limits  io^osed  by  a  criterion 
or  set  of  criteria)  for  the  operation  of  the  system. 

Thus,  it  is  understood  that  the  process  of  simulation  includes 

both  the  construction  of  the  model  and  the  analytical  use  of 

the  model  for  studying  the  system. 

Topics  relevant  to  a  fundamental  study  of  simulation  are 
those  that  deal  with  and  define  the  key  words  in  the  above 
definition:  system,  model.  This  chapter  describes  the 
basic  concepts  of  what  constitutes  a  system,  how  a  model 
can  be  used  to  represent  a  system,  and  how  a  system  and  model 
description  affect  the  development  of  system  simulation. 

A.  SYSTEMS 

Webster's  New  Collegiate  Dictionary  (1980,  p.  1175) 
defines  a  system  as  "a  regularly  interacting  or  interdependent 
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group  of  items  forming  a  unified  whole. ”  For  the  purposes 
of  this  thesis  a  more  specific  and  operational  definition 
will  be  used,  given  by  Fitzgerald  [Ref.  5] : 


A  system  ceui  be  defined  as  a  network  of  interrelated 
procedures  that  are  joined  together  to  perform  an 
activity  or  to  accomplish  a  specific  objective.  It 
iS/  in  effect,  all  the  ingredients  which  make  up  the 
whole,  ^d  a  procediire  is  a  precise  series  of  step- 
by-step  instructions  that  explain 

•  VAiat  is  to  be  done. 

•  Who  will  do  it. 

•  When  it  will  be  done. 

I  '  How  it  will  be  done. 

Systems  are  distinguished  from  one  another  by  their  static 
and  dynamic  structures.  The  entities  (i.e.,  a  job)  that  make 
I  up  a  system,  along  with  their  associated  attributes  (i.e.,  job 

priority)  and  membership  relationships  (conncection  between 
entities)  define  its  static  structure.  The  activities  in  which 
I  *  these  entities  engage  specify  its  dynamic  structure.  The  re¬ 

lationships  between  the  attributes  of  a  given  entity  are  called 
functions  and  very  often  are  being  given  in  some  form  of  mathe¬ 
matical  expression.  Collectively,  the  attributes  (i.e.,  their 
values)  of  an  entity  define  its  states,  and  the  states  of  the 
entities  of  a  system  define  the  state  of  the  system.  These  entity 
states  can  be  viewed  from  both  a  static  or  dynamic  system 
standpoint  and  provide  a  significeuit  tool  for  examining  system 
behavior.  That  is,  they  can  be  viewed  at  a  single  point  in 
time  or  over  a  series  of  points  in  time. 

Every  system  has  three  basic  features.  It  has  an  environment 
in  which  it  exists.  It  has  a  set  of  boundaries  which  distinguish 
the  system  from  the  rest  of  its  environment.  And  it  has  a 
set  of  subsystems  which  are  its  components  parts  [Ref.  6]. 
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Objectives  for  Analyzina  a  System 


The  objective  in  studying  system  behavior  au:e  to  learn 
how  the  state  transitions  occur,  to  predict  transitions  in  state, 
and  to  control  state  transitions.  One  way  in  which  these  objec¬ 
tives  can  be  satisfied  is  through  the  evaluation  of  alternatives 
[Ref.  6].  An  evaluation  of  alternatives  approach  is  concerned  with 
the  relationship  between  system  inputs ,  which  induce  transitions  in 
state  and  system  outputs  which  measure  these  transitions  in  state. 

There  are  three  common  properties  to  the  evaluation  of  the 
alternative  approach:  The  first  is  a  straightforward  analysis  in 
which  the  system  and  its  inputs  are  specified  and  the  outputs  are 
then  measured.  The  second  is  broader  in  purpose  and  can  be  used 
to  evaluate  the  relative  merits  of  alternative  system  design 
when  input  is  given  and  certain  desiraUale  characteristics  for  the 
output  are  specified.  The  third  and  final  variant  is  when  the 
system  is  specified  and  an  effort  is  made  to  determine  the 
input  that  produces  the  desired  output.  In  this  research,  a 
combination  of  the  second  cuid  third  approaches  is  used. 

2.  System  Classification 


Systems  c£Ui  be  classified  in  a  number  of  ways  [Refs.  4,5,6]. 
Unfortunately,  none  is  completely  satisfactory,  although  each  serves 
a  particular  purpose.  Some  of  these  classification  schemes 
are  as  follows: 

a.  Natural  vs  Man-made 

The  distinction  between  the  two  is  obvious. 


b.  Open  vs  Closed 

The  distinction  here  is  not  so  obvious.  A  closed 


system  is  one  which  automatically  controls  or  modifies  its 


own  operation  by  responding  to  data  generated  by  the  system  it¬ 
self,  thus  it  is  one  which  Ceui  exist  in  a  number  of  alternative 
environments.  An  open  system,  on  the  other  hand,  is  one  which 
does  not  provide  for  its  own  control  or  modification,  thus  it 
is  one  which  only  exists  in  a  peurticular  environment. 

c.  Discrete  vs  Continuous 

The  distinction  between  the  two  depends  upon  the  way 
that  they  change  from  one  state  to  another.  The  distinction  can 
best  be  seen  by  considering  the  values  that  can  be  taken  on  by 
the  variables  that  characterize  the  state  of  the  system  [Ref.  4] . 
Continuous  systems  include  variables  that  can  take  on  any  real 
value  in  a  prescribed  interval  or  intervals.  Discrete  systems 
include  variables  that  can  take  on  only  one  particular  value 
from  among  a  finite  (but  possibly  very  large)  set  of  values. 

d.  Deterministic  vs  Stochastic 

The  distinction  between  the  two  depends  upon  the 
causal  relationship  between  input  and  output.  The  output  of  a 
deterministic  system  can  be  predicted  completely  if  the  input 
and  the  initial  state  of  the  system  are  known.  That  is,  fora 
particular  state  of  the  system,  a  given  input  always  leads  to  the 
same  output.  A  stochastic  system  in  a  given  state,  on  the  other 
hand,  may  respons  to  a  given  input  with  any  one  among  a  range  of 
distribution  of  outputs.  For  a  stochastic  system — given  the  input 
and  the  state  of  the  system— it  is  possible  to  predict  only  the 
range  within  which  the  output  will  fall  and  the  frequency  with 
which  various  particular  outputs  will  be  obtained  over  many 
repetitions  of  the  observation.  It  is  impossible  to  predict 
the  particular  output  of  a  single  observation  of  the  system. 


e.  Adaptive  vs  Non-adaptive 

As  their  names  imply,  these  systems  either  can 
or  c2mnot  react  to  changes  in  their  environment. 

The  above  distinction  takes  on  real  significance 
vAien  the  system  is  being  analyzed.  Conclusions  reached  eJsout 
an  open  system  must  be  carefully  qualified  in  terms  of  the 
system  environment.  Also  the  analysis  of  an  adaptive  system 
requires  a  complete  description  of  how  the  system  environment 
causes  changes  in  system  state. 

3.  System  State 

The  state  of  a  system  is  determined  by  the  values  of 
the  attributes  of  the  system  entities.  Depending  on  the  view 
concerning  activities,  whether  they  interact  at  discrete 
points  or  over  periods  of  time,  there  can  be  attributes  asso- 
ciated  with  dynamic  as  well  as  static  system  structures.  That 
is,  an  activity  can  be  fully  or  partially  completed,  be  in 
progress  or  terminated,  be  waiting  for  another  activity  to 
occur  or  be  interrupting  another  activity,  etc.  In  a  general 
view,  there  is  no  conflict  in  the  description  of  state  as  a 
static  or  dyn^uaic  phenomenon,  since  at  all  times,  whether 
between  state  changes  in  a  static  structure,  or  at  system 
activity  interactions  in  a  dynamic  structure,  the  concept  of 
a  system  state  is  completely  defined. 

Viewed  at  a  point  in  time,  a  system  is  always  in  one 
of  a  nvindDer  (perhaps  ennormous)  of  states.  Viewed  over  a 
period  of  time,  a  system  passes  through  a  succession  of  states 


as  its  entities  undergo  system  activities,  change  their 
attribute  values  and  relationships,  and  become  eligible  for 
subsequent  activities.  Thus,  the  emalysis  of  a  given  system 
is  the  study  of  its  transitions  in  state  as  time  passes. 

The  state  transition  of  a  system  is  described  by  two 
attributes  (i.e.,  their  valties)  :  magnitude  and  delay  [Ref. 

6].  The  magnitude  of  a  state  transition  refers  to  the  abso¬ 
lute  difference  in  an  attribute's  value  over  a  specified  period 
of  time  compared  to  its  v^lue  before  the  state  changes.  The 
delay  associated  with  a  transition  of  state  refers  to  the 
passed  time  between  the  arrival  of  an  input  euid  the  actual 
tremsition  of  state  caused  by  the  input.  Delay  determines 
that  an  input  can  cause  a  transition  state  immediately  upon 
its  arrival,  at  some  time  after  its  arrival,  or  over  a  period 
of  tixDS  following  its  arrival  (continuously)  . 

4.  System  Response 

When  viewed  together,  the  magnitude  and  delay  in  a 
transition  of  state  describes  system  response.  That  is,  the 
way  in  whidi  the  system  reacts  to  a  given  input.  Five  possible 
system  responses  are  sho%m  in  Figure  2.1  [Ref.  6].  A  stable 
system  response  is  shown  in  Figures  2.1a,  2 . lb ,  and  2.1c.  In 
a  stable  response,  the  system  moves  over  some  finite  period 
of  time  to  a  permanent  new  state  of  equilibrium  (steady  state) 
of  finite  value  as  a  result  of  a  single  input  to  the  system. 


Two  definitions  are  ioqportant  in  considering  when  to 
begin  to  measure  output  in  a  simulation  experiment: 


Time 


b .  Delay 


<1 


Figure  2.1.  Possible  System  Responses 
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a.  The  system  is  said  to  be  in  the  empty  or  idle  state, 
if  the  initial  value  of  the  state  vari£d}le  under  considera¬ 
tion  is  zero. 

b.  The  system  is  said  to  be  in  a  transient  state,  if  it 

is  in  the  process  of  moving  from  one  steady  state  to  another. 

Results,  as  a  general  rule,  should  be  taken  only 
after  a  steady  state  is  reached,  following  the  tremsition 
period  from  an  initial  empty  or  idle  system  state.  This 
reduces  the  influence  of  the  systems  behavior  during  the 
tremsition  period  on  the  overall  evaluation  of  the  system. 

An  unstable  system  response  is  shown  in  Figures  2. Id,  emd  2.1e 
Figtore  2. Id  exhibits  an  explosively  xinstable  response  where 
the  value  of  the  state  variable  continues  to  increase  with  the 
time  without  convergence  to  a  new  finite  value.  Figure  2.1e 
shows  a  non-explosive  unst2U>le  system  in  which  an  equilibrium 
level  exists  but  where  system  response  oscillates  aroxind  this 
level  but  does  not  converge  to  it. 

5.  System  Performance 

Earlier,  three  objectives  were  given  for  emalyzing  a 
system.  They  were  to  learn  how  system  state  transitions  occur 
to  predict  transitions  in  state,  and  to  control  transitions 
in  state.  These  specific  objectives  for  system  analysis  re¬ 
sult  from  a  desire  or  need  to  improve  system  performance. 

In  turn,  system  performance  is  reflected  in  the  sequence  of 
states  that  a  system  undertaUces  over  a  given  period  of  time. 
Normally,  these  sequences  of  system  states  are  manipulated 


21 


in  some  way  by  the  system  analyst  to  provide  a  series  of 
performance  measures. 

The  idea  of  what  composes  a  performance  measure  varies 
with  the  system.  For  example,  in  Chapter  III  of  this  thesis 
the  essential  measures  of  Local  Area  Networks  (LAN)  perfor¬ 
mance  will  be  discussed.  These  measures  would  have  little 
or  no  significance  if  they  were  applied  to  the  evaluation 
of  another  system  (e.g..  Water  resources  system). 

In  conducting  the  analysis  of  a  complex  system,  it 
is  often  desired  to  obtain  only  a  "feel"  for  system  perfor¬ 
mance.  It  is  exactly  this  type  of  analysis  effort  that  can 
greatly  benefit  from  a  careful  consideration  of  which  per¬ 
formance  measures  will  provide  the  needed  "feel”  or  under- 
stamding  of  the  system.  Failure  to  devote  adequate  time  to 
determine  the  performance  measures  that  will  be  used  can  lead 
to  confusion  and  delay  in  the  amalysis  process. 

6.  System  Optimization 

One  objective  in  analyzing  a  system  and  in  measuring 
its  performance  is  to  optimize  system  performance,  that  is, 
to  improve  the  effectiveness  of  the  system.  Generally,  this 
system  optimization  involves  the  identification  of  certain 
critical  system  aspects  and  the  development  of  certain  pro¬ 
cedures  to  control  these  aspects.  Usiaally,  however,  a  number 
of  these  critical  system  aspects  are  beyond  the  analyst's 
observation.  Such  aspects  put  constraints  on  system  behavior 
^uld  prevent  total  system  optimization.  In  this  case  the 
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final  objective  must  be  modified  to  one  of  optimizing 
performance  under  certain  constraints.  As  it  is  often  the 
case  with  the  large  complex  systems,  optimization  of  the 
entire  system  is  virtually  impossible,  due  to  the  size  of 
the  system  and  the  complexity  of  the  relationships  among 
the  various  subsystems.  Thus,  optimization  can  and  mvist 
occur  with  regard  to  individual  subsystems  or  selected 
groups  of  subsystons. 

B .  MODELS 

The  initial  step  in  anetlyzing  a  system  beyond  defining 
system  components  and  identifying  possible  performance 
measures,  is  to  build  a  model  of  the  system. 

A  model  is  a  representation  of  an  object,  system,  or 
idea  in  some  form  other  than  that  of  the  entity  itself.  Its 
purpose  is  ustially  to  aid  in  explaining,  understanding,  or 
is^roving  a  system  [Ref.  3] . 

1.  Function  of  Models 

The  concept  of  representing  some  object,  system,  or 
idea  with  a  model,  is  so  general  that  it  is  difficult  to 
classify  all  the  functions  that  models  perform.  Fishman 
[Ref.  6],  recognizes  that  a  model  perfoznns  the  following 
functions : 

a.  En^d>les  an  investigator  to  organize  his  theoretical 
beliefs  and  empirical  observations  about  a  system 
^uld  to  deduce  the  logical  implications  of  this 
organization. 


b. 


Leads  investigator  to  improved  system  understanding. 


c.  Brings  into  perspective  the  need  for  detail  and 
relevance . 

d.  Expedites  the  speed  with  which  an  analysis  ceui  be 
accomplished. 

e.  Provides  a  framework  for  testing  the  desirability 
of  system  modifications. 

f.  Is  easier  to  manipulate  than  the  system  is. 

g.  Permits  control  over  more  sources  of  variation  than 
direct  study  of  a  system  would  allow. 

h.  Is  generally  less  costly. 

Summarizing  the  eUsove  functions,  a  model  may  serve  one 
of  two  major  purposes:  descriptive,  for  explaining  and/or 
understanding,  and  prescriptive,  by  predicting  and/or 
duplicating  behavior  characteristics. 


2.  Model  Classification 

Models  can  be  classified  in  a  variety  of  ways  and 
can  take  many  forms.  A  model  can  be: 

a.  Iconic  like  a  scale  model  airplane.  This  model  resem¬ 
bles  the  system  being  studied. 

b.  Analog  like  an  electric  circuit  that  behaves  like  a 
mech^mic^d  system.  In  this  model  a  property  of  the  real 
system  is  represented  by  a  substituted  property  which  often 
behaves  in  a  similar  way. 

c.  Symbolic  like  a  set  of  equations.  This  model  uses  a 
symbol  rather  than  a  physical  device  to  represent  an  entity 
of  the  system. 

Iconic  models  are  good  visual  aids  but  are  usually  not  good 
for  predicting  or  explaining  the  behavior  of  the  systems. 
Symbolic  models  are  good  for  prediction  and  explanation  but 


offer  Ixttle  as  visual  aids.  Thus,  different  models  exist 
for  different  purposes.  This  thesis  concerns  itself  with 
symbolic  models,  so  a  further  classification  of  those  models 
follows . 

3.  Symbolic  Models 

A  symbolic  model  represents  a  system  using  mathemati* 
cal  equations  and  algorithms.  Symbolic  or  mathematical 
models  can  be  distinguished  according  to  their  characteris¬ 
tics  into  four  classification  schemes  as  follow  [Refs.  6,  7, 

8,  9]: 

a.  Analytical  vs  Nvimerical 

In  an  analytical  model  it  is  possible  to  deduce 
the  behavior  of  the  system,  directly  from  the  system's  mathe¬ 
matical  representation.  Kirchoff's  law  is  am  example  of 
an  analytical  model.  A  numerical  model  implies  that  an  exact 
deduction  of  the  system's  behavior  is  not  feasible  but 
numerical  methods  can  provide  descriptions  of  the  behavior  for 
certain  system  aspects  as  are  defined  in  the  numerical  model. 
Numerical  integration  is  an  example  of  a  numerical  model. 

b.  Continuous  vs  Discrete 
Continuous-change  models  are  used  to  represent 

systems  that  consist  of  a  continuous  flow  of  information  or 
material  (e.g.,  flow  of  gas  in  a  pipeline).  Continuous  models 
are  usually  represented  by  differential  equations  which  des¬ 
cribe  rate  of  change  of  the  variables  over  time.  Discrete- 


change  models  represent  systems  in  which  changes  in  the 


state  of  the  system  are  discrete  (e.g.,  messages  arriving 
at  a  node  of  a  network) .  Discrete  models  are  usually  repre¬ 
sented  by  queueing  theory  and  stochastic  processes. 

c.  Static  vs  Dynamic 

A  static  model  either  does  not  take  into  con¬ 
sideration  the  passage  of  time  or  describes  the  state  of 
a  system  at  a  specified  point  in  time.  On  the  other  hand, 
a  dynamic  model  explicitly  recognizes  the  passage  of  time. 

A  dynamic  model  may  specify  also  the  relationships  between 
the  various  system  states  at  different  points  in  time. 

d.  Deterministic  vs  Stochastic 

In  a  deterministic  system  model,  all  the  ^.itities 
of  the  system  have  fixed  mathematical  o<  '.ogiG:ti>*  relation¬ 
ships  to  each  other.  Thus,  the  behavior  of  the  system  is 
completely  determined  by  these  relationships.  In  a  stochas¬ 
tic  model,  part  of  the  entity  relationships,  at  least,  vary 
in  a  remdom  fashion.  Thus,  an  analyst  can  at  best,  obtain 
an  average  description  of  a  system  behavior  by  using  a 
stochastic  model. 

There  are  a  number  of  different  model  descriptions 
possible,  when  the  four  sets  of  model  characteristics  are 
combined. 

4.  Scope  of  a  Model 

A  model  is  used  to  predict  results  euid  describe  the 
way  the  results  are  determined  when  a  set  of  input  conditions 
is  given;  that  is,  the  analyst  is  concerned  with  both  system 
response  and  system  dynamics. 


During  the  model  building  process  the  analyst  must 
continuously  deal  with  the  problem  of  balancing  the  need  for 
structural  detail  in  describing  the  system,  with  the  modeling 
resources  and  capediilities  available.  By  its  nature,  a  sys¬ 
tem  model  is  a  formalized  abstraction  of  reality,  thus  the 
more  structural  detail  it  includes,  the  more  it  resembles  the 
actual  system.  Additionally,  increased  modeling  detail  pro¬ 
vides  an  increased  capability  for  observing  system  response 
in  a  given  system  modification  or  series  of  system  modifica¬ 
tions  [Ref.  10].  That  is,  increased  detail  provides  more 
combinations  of  system  modifications  which  ceui  be  made  and 
more  aspects  of  system  response  vdiich  can  be  measured. 

While  it  seems  to  be  desirable  to  include  as  much 
modeling  detail  as  possible  in  a  model,  there  are  several 
problems  which  result  from  this  increased  detail.  First, 
increased  detail  makes  the  modeling  process  more  difficult. 
Second,  it  usually  shifts  the  model  characterization  from 
emalytical  to  numerical.  Third,  and  most  important,  the 
analyst  often  does  not  understemd  the  system  to  a  degree  that 
will  allow  specification  of  the  system  in  the  desired  detail. 
Fourth,  and  final,  the  inclusion  of  increased  detail  may  place 
an  increased  and  unacceptable  demand  on  analysis  resources, 
i.e.,  time,  personnel,  facilities,  etc.  \ 

Every  type  of  system  model  must  limit  the  amount  of 
structural  detail  it  includes.  The  degree  to  which  this  de¬ 
tail  is  limited  must  be  determined  through  a  process  of 
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balancing  the  original  system  analysis  objectives  against 
the  analysis  resources. 

Although  one  of  the  purposes  of  building  a  system 
model  is  to  improve  the  2uialyst's  understanding  of  the  sys> 
tern,  there  are  three  hazards  associated  with  achieving  this 
purpose  [Ref.  6]  :  First,  there  is  no  guarcuitee  that  the 
results  of  the  modeling  effort  will  prove  to  be  useful. 
Sometimes  this  type  of  failure  is  due  to  a  lack  of  adequate 
resources,  but  more  often,  it  is  a  case  of  an  improper 
balance  between  available  resources  euid  the  system  analysis 
objectives.  The  second  hazard  deals  with  the  analyst  him¬ 
self,  who  may  think  of  his  particular  description  of  the 
system  as  the  most  accurate  representation  of  reality,  when, 
in  fact,  it  is  not.  The  third  and  most  critical  hazard  in¬ 
volves  the  use  of  the  model  to  analyze  aspects  of  the  system 
which  the  model  was  not  intended  to  emalyze. 

C.  DISCRETE  EVENT  SIMULATION 

This  section  presents  concepts  applicable  to  the  con¬ 
struction  of  a  discrete  event  simulation  model.  An  event 
denotes  a  transition  in  the  state  of  a  system  entity.  Thus, 
a  discrete  event  simulation  model  can  be  defined  as  a  model 
of  system  behavior  in  which  entity  state  transitions  are 
represented  as  a  series  of  events  occurring  at  discrete 
points  in  time. 

Following  is  a  discussion  of  event  timing  and  entity- 
attribute  relationships.  The  purpose  of  the  discussion  is  to 
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establish  their  importance  in  the  realization  of  a  discrete 
event  system  model.  Additionally,  alternative  discrete 
event  modeling  techniques  are  discussed. 

1.  Event  Timing 

The  actual  approach  to  the  discrete  event  modeling 
of  a  p^u:ticular  system  depends  on  the  nature  of  the  event's 
inter-arrival  rates.  That  is,  whether  these  inter-arrival 
rates  are  deterministic  or  random  in  nature.  If  the  inter¬ 
arrival  rates  are  deterministic,  then  the  modeling  techniques 
used  must  reflect  inter-arrival  rates  which  vary  according 
to  a  fixed  relation  or  are  equal.  If  the  inter-arrival  rates 
are  random,  then  the  modeling  techniques  must  reflect  their 
randomness . 

With  either  type  of  inter-arrival  rate,  the  occurrence 
of  an  event  specifies  a  transition  in  the  state  of  the  system. 
The  states  of  system  entities  remain  constant  between  the 
occurrence  of  events,  so  there  is  no  need  to  account  for 
this  dead  time  in  a  discrete  event  system  model.  When  a 
particular  event  occ\irs  and  all  the  state  treuisitions  asso¬ 
ciated  with  the  event  are  made,  then  simulated  time  is  advanced 
to  the  time  of  the  next  event,  where  once  again  the  required 
state  tremsitions  are  made.  This  next  event  technique  allows 
the  analyst  to  compress  time. 

2.  Entity-Attribute  Relationships 

There  are  two  types  of  primary  structural  relation¬ 


ships  which  play  a  significant  role  in  the  modeling  of  a 


system.  The  first  are  the  mathematical  relationships  which 
exist  between  the  attributes  associated  with  the  various  sys 
tern  entities.  Sometimes  the  specification  of  the  mathemati" 
cal  relationships  for  a  system  serve  to  describe  completely 
the  way  in  which  system  state  transitions  occur.  The  second 
are  the  logical  relationships  which  exist  between  system  com 
ponents.  A  logical  relationship  checks  to  see  if  a  certain 
condition  holds.  If  it  does,  a  given  action  is  taken.  If 
it  does  not  hold,  an  alternative  action  is  taken.  Normally, 
a  system  is  not  modeled  through  the  use  of  only  one  type  of 
relationship,  but  through  a  mixture. 

3.  Alternative  Modeling  Techniques 

There  are  three  main  ways  of  building  discrete  event 
system  models  [Ref.  6] . 

a.  The  event  scheduling  technique  emphasizes  the  detailed 
description  of  the  steps  that  occur  during  the  processing 

of  an  event.  Usually,  an  event  naturally  has  a  distinct 
series  of  steps  associated  with  it. 

b.  The  activity  scanning  technique  emphasizes  the  review 
of  all  activities  in  a  simulation  to  determine  which  can  be 
initiated  emd  terminated  during  the  occurrence  of  a  given 
event . 

c.  Finally,  the  process  interaction  technique  emphasizes 
the  continuous  progress  of  an  entity  through  the  system. 

That  is,  from  its  arrival  event  to  its  departure  event. 


The  development  of  the  three  techniques  mentioned 
above  has  been  associated  directly  with  the  development  of 


discrete  event  simulation  programming  lemguages.  In  particu¬ 


lar,  GASP  and  SIMSCRIPT  use  the  event  scheduling  technique, 

CSL  uses  the  activity  scanning  technique,  and  GPSS  and 
SIMULA  use  the  process  interaction  technique  [Ref.  4] . 

4.  Queueing  Models 

The  majority  of  discrete  event  simulation  models  are 
reducible  to  a  series  of  queueing  problems.  In  a  queueing 
problem,  an  arrival  event  occurs  and  causes  £ui  entity  to 
demand  a  service  to  be  performed.  The  system  responds  to 
the  demauid  for  service  either  by  performing  it  or  by  keeping 
the  entity  waiting  (puts  it  in  a  queue)  until  it  can  per¬ 
form  the  required  service. 

The  objective  in  queueing  oriented  problems  is  usually 
to  analyze  how  system  performance  varies  in  response  to 
changes  in  system  workload,  system  resource  characteristics, 
or  task  selection  schemes.  In  a  given  workload,  system 
resources,  and  task  selection  must  be  resolved  and  explicitly 
specified  in  the  simulation  model. 


I.  LOCAL  ABBA  NETWORK  COMPONENTS  AND  PERFORMANCE  MEASURES 


A.  GENERAL 

A  computer  network,  in  general,  is  any  system  composed  of 
one  or  more  computers  amd  associated  terminals,  communica¬ 
tion  devices,  transmission  facilities,  and  software/hardware 
to  facilitate  the  flow  of  information  between  terminals  and/ 
or  computers. 

Metcalfe  and  Boggs  [Ref.  11],  distinguish  three  types  of 
networks  based  on  the  parameters  of  bit  rate  and  separation 
between  computers : 

Activity  Separation  Bit  Rate 

Remote  networks  >  10  Km  <0.1  Mbit/sec 

Local  networks  0.1--10  Km  0.1—10  Mbit/sec 

Multiprocessors  <  0 . 1  Km  >10  Mbit/sec 

At  one  end  of  the  above  spectrum  of  activities  there  is 
a  group  of  dissimilar  computers  tied  together  by  a  communi¬ 
cation  network,  which  enables  a  user  to  take  advantage  of  a 
variety  of  computing  resources,  while  at  the  other  end  there 
is  an  attempt  to  convert  a  collection  of  serial  processors 
into  parallel  processors.  Since  local  networks  are  near  the 
middle  of  this  spectrum,  they  may  be  built  to  gain  the  re¬ 
source  sharing  of  computer  networking  along  with  the  parallel¬ 
ism  of  multiprocessing. 

1.  LAN  Definition 

As  its  ncune  implies,  a  LAN  links  computing  system 
components  located  within  a  geographically  restricted  area, 


such  as  a  building  or  an  office  complex.  There  is  no  widely 
acceptable  definition  for  a  LAN.  It  should  be  noted  that  a 
panel  discussion  held  during  the  Third  Conference  on  Local 
Computer  Networks — a  conference  devoted  to  develop  a  defini-* 
tion  of  a  local  computer  network — failed  to  achieve  a  defini¬ 
tion  acceptable  to  all  participants.  A  definition  for  local 
networks,  which  has  been  proposed  by  Franck  [Ref.  12],  is 
given  below.  He  pictures  a  local  computer  network  as  con¬ 
sisting  of  three  essential  ingredients: 

a.  A  high-speed  transmission  medium  for  data  transmission 
over  a  "limited”  distance.  The  nature  of  the  transmission 
medium  and  the  topology  of  the  network  are  left  unspecified. 

b.  Several  network  adapters  attached  to  this  transmission 
medium  which  serve  as  line  interfaces  for  computing  equipment. 
The  adapters  transmit  data  on  the  transmission  medium. 

c.  Computing  system  components  that  cam  be  attached  to 
an  adapter. 

Franck's  illustration  of  his  definition  is  shown  in  Figure 
3.1. 

2 .  Overview 

Based  on  the  previous  definition  certain  topics  rele¬ 
vant  to  a  fundamental  study  of  the  LAN  components  are  those 
that  deal  with  and  define  the  key  words:  topology,  physical 
transmission  medium,  and  communication  protocols  for  network 
management.  To  accomplish  an  effective  network  management 
is  is  essential  that  a  series  of  basic  transmission  control 
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procedures  be  established  to  ensure  the  efficient  and  accurate 
transfer  of  information  within  the  network.  These  procedures 
called  network  protocol,  along  with  related  aspects  as 
channel  access,  flow  control,  and  error  control  are  exten¬ 
sively  covered  in  Ref.  (18)  and  not  included  here. 

This  chapter  will  discuss  in  general,  the  LAN 
topologies,  the  tr2Uismission  medium,  and  the  network  perfor- 
iReUice  measurements  which  are  fundamental  ingredients  in  any 
LAN  analysis  or  design  effort.  It  should  be  noted  that  the 
specific  characteristics  of  the  network  components  depend 
greatly  upon  the  manner  in  which  the  LAN  is  implemented. 

B .  TOPOLOGY 

Network  topology  is  the  spatial  pattern  formed  by  a  net¬ 
work's  digital  devices,  called  nodes,  and  connecting  links. 
Many  characteristics  of  computer  networks  are  determined  or 
influenced  by  their  topology.  Some  qualitative  attributes 
can  be  inferred  directly  from  the  topology  of  the  network 
independently  of  the  particular  implementation  [Ref.  13] . 

Such  attributes,  among  others,  may  be: 

1.  Modularity,  the  ability  to  make  incremental  changes  in 
system  capability. 

2.  Flexibility  which  measures  the  degree  of  freedom  in 
adding  a  new  element  to  the  network. 

3.  The  ability  for  graceful  degradation. 

As  the  number  of  network  elements  increases,  the  number 
of  ways  one  can  interconnect  the  various  elements  increases 


rapidly.  Thus,  it  is  not  easy  to  classify  all  possible 
topologies  for  a  network.  This  section  will  discuss  only 
the  basic  topologies  used  in  computer  networks:  Bus,  ring, 
star,  and  mesh.  The  bus  and  the  ring  are  characteristics  of 
new  decentralized  network  schemes  intended  for  computer  com¬ 
munications.  The  star  is  widely  used  in  long-distance  net¬ 
works  and  in  conventional  (centralized)  local  networks,  such 
as  time-sharing  systems.  The  mesh  is  characteristic  of  long¬ 
distance  packet-switched  (decentredized)  networks. 


The  bus  topology  employs  a  shared  transmission 
facility,  called  a  bus,  for  information  exchange  between 
several  nodes  (computers,  peripherals) .  Figures  3.2a  and 
3.2b  illustrate  distributed  and  centrally  controlled  bus 
topologies  [Ref.  14].  In  Figure  3.2a,  all  nodes  are  identical 
in  nature  but  a  technique  must  be  developed  to  eliminate 
contention  for  the  use  of  the  bus.  In  Figure  3.2b,  a  single 
control  node  manages  the  traffic  flows  between  every  pair 
of  nodes,  i.e.,  all  nodes  must  communicate  with  control  node 
C  before  they  set  up  a  call. 

The  bus  itself  is  employed  in  a  broadcast  mode,  all 
nodes  "hear"  a  message.  The  major  advantage  of  a  bus  topology 
is  its  simplicity.  It  is  easy  to  add  or  delete  processing 
elements  and  by  using  passive  connections  the  reliability  is 
improved.  The  principal  disadvantage  of  this  topology  is 
the  vulnerability  of  the  network  to  a  failure  of  the  bus 
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Figure  3.2.  Bus  Topology 


itself.  Howe>^er,  nodal  failures  will  generally  have  no 
impact  on  the  operation  of  other  nodes. 

2 .  Ring  Topology 

A  network  topology  is  characterized  as  ring,  if  a 
collection  of  processing  elements  (computers,  peripherals) 
are  interconnected  via  a  communication  path  in  the  form  of  a 
loop.  Two  varieties  of  loop,  or  ring,  topology  are  shown  in 
Figures  3.3a  and  3.3b  [Ref.  14].  In  Figure  3.3a,  each  node 
acts  as  a  message  s tore -and* forward  node.  In  Figure  3.3b, 
each  node  receives  bits  only  in  assigned  time  slots.  If  all 
nodes  of  the  loop  are  of  the  same  type,  a  distributed  ring 
topology  results,  but  if  one  node  is  a  loop  supervisor  then 
a  centrally  controlled  ring  topology  results.  In  general, 
traffic  on  the  loop  flows  in  one  direction  only  and  so  a 
break  in  the  loop  at  any  point  disables  it.  Consequently, 
each  connection  to  the  network  is  complex  because  hardware 
is  required  to  keep  the  network  functioning  even  when  a  node 
fails. 

3.  Star  Topology 

A  star  topology  is  characteristic  of  many  conven¬ 
tional  local  and  long-distance  networks.  This  arrangement 
connects  each  station  to  a  central  facility  responsible  for 
managing  all  communications.  Its  structure  is  shown  in  Figure 
3-4.  Both  the  advantages  and  disadvantages  of  this  topology 
arise  from  this  centralization.  Communications  and  resource 
management  can  be  efficiently  handled,  but  the  limitations 
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Figxire  3.4.  star  Topology 


and  reliability  of  the  central  unit  determine  all  the  net¬ 
work  performance  characteristics. 

4.  Mesh  Topology 

A  mesh  topology  is  widely  used  in  long-dist^ulce 
decentralized  ( "packet-switched”)  networks.  In  this 
arrangement  all  the  nodes  are  connected  arbitrarily  as  shown 
in  Figure  3.5.  The  star  etnd  the  mesh  topologies  frequently 
appear  in  combination  in  long-distemce  networks.  That  is, 
a  mesh  network  may  serve  as  the  hub  of  a  subsidiary  star 
network.  By  providing  alternative  routings,  the  Mesh  topology 
has  relatively  high  reliedbility ,  euid  it  allows  for  uncon¬ 
strained  network  reconfiguration. 

C.  TRANSMISSION  MEDIUM 

Though  the  topology  selected  determines  many  network 
issues,  it  is  basically  independent  of  the  choice  of  the 
tremsmission  medium.  The  transmission  medium  provides  the 
physical  data  communication  links  of  the  network,  i.e.,  high 
speed  paths  for  electrical  tr^ulsmission  between  two  or  more 
nodes  or  terminals.  GenereU.ly,  local  networks  can  use  an 
assortment  of  media  which  are  technologically  appropriate  to 
a  given  application. 

The  four  most  frequently  used  treuismission  media  in  LAN 
are:  twisted  wire-pair,  fiber-optics,  baseband  coaxial  caJsle 
and  broadband  coaxial  cable  (TV-cable) . 
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Twisted  wire-pair  is  basically  used  to  connect  stations 
in  a  low-speed  network  where  the  required  bemdwidth  does  not 
exceed  19  Kbits  per  second  [Kef.  15] . 

Fiber-optic  cable  allows  the  construction  of  very  high 
performance  and  secure  networks.  The  advemtages  of  fiber¬ 
optic  are  many,  and  its  potential  is  very  promising. 

Generally  it  can  provide  [Ref.  16] : 

1.  High-speed  data  tremsmission  caped>ility  (up  to  one 
gigabits  per  second) . 

2.  Relative  immunity  to  electromagnetic  and  radio  fre¬ 
quency  interferences. 

3.  Higher  degree  of  communication  security. 

4.  Large  reduction  of  the  bit  error  rate  (one  bit  per 
billion)  .  With  ctirrent  technology  the  fiber-optic  cable  is 
not  a  practical  medium  for  bus  networks  because  of  the  lack 
of  cable  taps. 

Most  local  computer  networks  use  coaxial  cable  because 
it  allows  very  high  data  rates  over  distances  up  to  several 
miles  without  signal  regeneration.  A  coaxial  ceUsle  is  used 
to  support  either  a  baseband  channel  or  a  broadband  channel. 
In  the  first  case  the  coeucial  cable  provides  a  single  channel 
i.e.,  digital  signals  are  placed  directly  on  the  cable.  In 
the  second,  the  cable's  bandwidth  is  divided  into  a  number 
of  independent  channels  by  employing  Frequency  Division 
Multiplexing  (FDM)  techniques. 
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D.  PERFORMANCE  MEASURES 

A  basic  understanding  of  computer  network  perfomuuice 
measurement  is  essential  during  the  computer  network  analy¬ 
sis  cycle,  i.e.,  from  problem  definition  to  simulation  ex¬ 
perimentation.  However,  the  measurement  of  con^uter  network 
performance  is  difficult  and  sometimes  totally  qualitative 
in  nature.  This  happens  due  to  the  great  number  of  different 
components  (hardware  and  software)  that  are  included  in  a 
computer  network. 

In  order  to  evaluate  a  network  effectively,  a  set  of 
performance  measures  must  be  employed.  This  set  must  encom¬ 
pass  the  network  topology,  communication  devices,  transmission 
facilities,  emd  transmission  management  software/hardware  and 
treat  them  as  a  single  system. 

The  National  Bureau  of  St^uldards  (NBS)  [Ref.  17]  defines 
nine  measures  for  evaluating  computer  network  system  perfor¬ 
mance.  They  are: 

1.  Availability 

2.  Transfer  Rate  of  Information  Bits  (TRIB) 

3.  Reliability 

4.  Accuracy  (or  Residual  Error  Rate — RER) 

5.  Channel-Establishment  Time 

6.  Network  Delay 

7.  Channel-Turnaround  Delay 

8.  Transparency 

9 .  Network  Security 


These  nine  measures  do  not  represent  all  the  possible  per¬ 
formance  measures,  but  they  are  considered  to  be  the  most 
essential  and  can  be  applied  to  any  computer  network  cuid 
provide  a  basis  for  comparison  with  other  networks.  In  a 
local  area  network,  a  computer  network  manager  might  be 
interested  also  in  the  utilization  rates  of  the  major  network 
components,  the  throughput,  the  various  network  queue  lengths, 
the  response  time,  the  mean  tremsmission  delay  time,  etc. 

All  of  the  nine  major  emd  as  many  as  are  necessary  of  the 
numerous  minor  network  performance  measures  should  be  con¬ 
sidered  throughout  the  acquisition  process,  from  network 
specification  to  network  operation.  The  degree  and  the  way 
in  which  these  measures  C2A  be  considered,  varies  during  the 
process  of  going  farom  a  conceptual  design  to  an  actual  in^le- 
mentation  in  hardware  and  software.  This  variance  is  due  to 
the  fact  that  some  performance  measures  can  be  applied  to  a 
network  while  it  is  still  in  the  design  phase  with  a  greater 
accuracy  than  some  of  the  other  performance  measures^  because 
some  measures  require  an  actual  selection  of  hardware  or  soft¬ 
ware  before  they  can  be  considered  accurately.  With  regard 
to  the  numerous  minor  performance  measures  that  can  be  con¬ 
sidered,  their  use  is  dependent  basically  on  the  desires  and 
needs  of  the  network  analyst  or  designer. 

With  respect  to  a  LAN  for  the  implementation  of  S?LICE 
fvinctions,  some  particular  performance  measures  are  of  great 
importemce  during  the  first  stages  of  network  design.  At 
these  stages,  in  fact,  a  designer  primarily  needs  to  estimate 
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message  propagation  delays  and  sustained  point  to  point 
throughput  rates.  Based  on  this  need  this  thesis  in  Qiapter 
IV  will  discuss  the  specifications  of  a  simulation  model  for 
evaluating  these  performance  measures.  Also,  after  adopting 
a  bus  topology  for  the  SPLICE  LAN  [Refs.  18,19],  performance 
measures  such  as  acquisition  probability,  waiting  time  and 
efficiency  of  the  channel  [Ref.  11] ,  can  be  considered. 

The  above  mentioned  performauice  measures  are  described 
as  follows: 

1.  Availability 

Availability  is  defined  in  Reference  (20)  as  "the 
portion  of  a  selected  time  interval  during  which  the  informa¬ 
tion  path  is  capable  of  performing  its  assigned  data  communi¬ 
cation  function."  Alternatively,  availability  can  be  defined 
in  teanns  of  the  ratio  MTTF/CMTTP+MTTR)  ,  where  MTTF  is  the 
mean  time  to  failure  and  MTTR  is  the  mean  time  to  repair  a 
device.  Thus,  availability  can  be  improved  by  increasing 
MTTF  and  decreasing  MTTR. 

Availability  of  a  computer  network  is  decreased  not 
only  by  component  failures  but  also  by  transmission  overloads 
caused  by  either  messages  which  contend  for  a  transmission 
channel  or  by  the  inability  of  the  transmission  processing 
equipment  to  handle  all  the  transmission  requests. 

One  common  problem  in  a  data  communication  system  is 
to  distinguish  between  very  short  term  failures  of  a  system 
such  as  those  that  cause  a  series  of  bit  errors  and  longer 
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term  failures  that  m^Jce  a  system  luiavailable  [Ref.  16]  .  The 
distinction  is  arbitrary  emd  is  left  to  the  user  to  define 
it  in  the  most  meaningful  terms.  Generally,  events  that 
cause  errors  on  communication  lines  are  not  defined  as  failures 
unless  the  facility  is  unusable  for  more  than  several  seconds 
or  minutes.  "Unusable"  may  mean  totally  unavailable  or 
having  such  a  high  error  rate  that  the  effective  tremsfer 
rate  (TRIB)  is  reduced  below  some  minimum  acceptable  value. 

2.  Transfer  Rate  of  Information  Bits  (TRIB) 

Tremsfer  rate  is  defined  as  the  ratio  of  the  number 
of  information  bits  accepted  by  a  receiving  terminal  during 
a  single  information  tr2uisfer  period  to  the  duration  of  the 
transfer  period.  Transfer  rate  is  expressed  in  bits  per 
second. 

In  calculating  network  transfer  rate,  the  trans¬ 
mission  channel  capacity  which  is  specified  by  the  medium  is 
the  upper  limit  for  the  tremsfer  rate.  In  an  operating  net¬ 
work,  the  transmission  managonent  procedures,  propagation 
delay,  channel  turnaroiind  time,  and  the  retransmission  of 
erroneous  messages  all  sxibtract  from  the  upper  limit  of  this 
transfer  rate.  It  should  be  noted  that  there  are  different 
definitions  of  what  exactly  constitutes  an  information  trans¬ 
fer.  Most  communication  engineers  consider  transmission 
block  headers  euid  trailers  to  be  part  of  the  useful  informa¬ 
tion  transferred.  On  the  other  hand,  some  applications- 
oriented  users  consider  such  headers  and  trailers  as  an  overhead 
factor  and  not  part  of  the  useful  information  transferred. 
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3.  Reliability 


Reliability  is  generally  defined  as  the  probedaility 
that  a  device  will  perform  without  failure  for  a  specified 
time  period  or  amount  of  usage.  It  is  importamt  to  network 
users  because  it  gives  the  probability  that  a  requested  task, 
using  networking  facilities,  has  been  successfully  completed. 
Expressed  as  a  percentage,  reliaibility  differs  from  availa¬ 
bility  in  that  it  describes  the  performemce  of  a  network  after 
it  has  accepted  a  request  from  its  source. 

4.  Accuracy 

Accuracy  or  Residual  Error  Rate  (RER)  is  defined  as 
the  ratio  of  undetected  error  bits  received  at  a  terminal 
station  to  the  nvonber  of  information  bits  transmitted  to 
that  terminal  station.  The  value  of  the  residual  error  rate 
is  computed  by  the  equation 

HER  =  (C^  -f 


where : 


C  s  the  number  of  erroneous  information  bits 
^  accepted  by  the  receiving  terminal  station. 

C  3  the  number  of  information  bits  transmitted, 
^  but  not  received  by  the  terminal  station. 

Cj  »  the  nuxnber  of  duplicate  information  bits 
^  accepted  by  the  receiving  terminal  station, 
though  they  were  not  intended  for 
duplication. 

C  »  the  number  of  information  bits  in  the  total 
^  treuismission. 


Cheuinel-establishiaent  time  is  defined  as  the  period 
of  time  required  for  network  communication  devices,  trans¬ 
mission  medium,  and  transmission  management  software/hardware 
to  connect  a  calling  terminal  station  with  a  called  terminal 
station.  The  channel-establishment  time  includes  both  the 
time  required  to  place  the  transmission  request  and  the  time 
required  for  the  network  to  complete  the  connection.  Ql^mnel 
establishment  time  is  normally  expressed  in  terms  of  seconds 
for  most  networks  but  some  newer  networks  are  designed  for 
establishment  times  of  not  more  than  several  hundred  milli¬ 
seconds  . 

In  networks  employing  transmission  techniques  such 
as  packet  switching,  the  conventional  interpretation  of 
channel-establishment  time  does  not  apply.  One  view  of  such 
networks  is  that  there  is  no  establishment  time,  since  the 
network  can  almost  always  accept  the  next  input  message  from 
the  sending  station  with  no  delay.  Another  view  is  that  this 
delay  is  imposed  on  every  data  excheuige  between  stations, 
since  virtual  channels  must  be  established. 

The  significance  of  a  channel-establishment  time 
varies  with  the  network  user  applications.  If  a  user  ex¬ 
pects  to  have  many  dialogs  he  may  find  channel-establishment 
time  to  be  very  important. 


6 .  Network  Dela' 


Network  delay  or  message  transfer  time  is  defined  as 
the  period  of  time  required  for  a  message  to  be  transmitted 
from  a  source  teinninal  station  to  a  receiving  terminal  sta¬ 
tion.  Network  delay  is  usually  expressed  in  terms  of  milli¬ 
seconds.  In  long-distcuice  networks  the  actual  value  of 
delay  depends  on  physical  distances. 

In  general,  the  network  delay  depends  on  the  charac¬ 
teristics  of  the  terminal  facilities,  i.e.,  their  buffer 
capacities,  the  volume  of  information  being  transferred, 
the  protocol  required,  and  the  reliability  of  the  transmission 
medium. 

In  an  interactive  environment  involving  a  series  of 
short  conversational  information  exchanges,  long  network  de¬ 
lays  are  undesirable.  This  is  because  the  data  input  process 
has  to  be  slowed  down,  becoming  thus  inconvenient  and  annoying 
to  the  user. 

7.  Channel-Turnaround  Delay 

Chaxinel-turnaround  delay  is  defined  as  the  time  re¬ 
quired  by  a  half-duplex  transmission  channel  to  reverse  its 
direction  of  transmission.  This  performance  measure  generally 
depends  on  the  type  of  channel  facilities  which  are  used  and 
it  can  remge  from  very  small  values  up  to  several  hundred 
milliseconds. 

Chcuinel- turnaround  delay  reduces  the  information 
transfer  rate  for  half-duplex  channels  by  increasing  the  time 
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required  for  a  block  of  data  acknowledgements.  As  with 
network  delay,  this  delay  can  be  reduced  to  some  degree  by 
using  longer  message  blocks  and  larger  storage  buffers. 

8.  Tramsparency 

Tramsparency  is  a  totally  qualitative  term  which 
describes  the  lack  of  code  or  procedural  constraints  which 
are  Imposed  on  network  information  processing  by  the  network 
communication  devices,  tramsmission  facilities,  and  trans¬ 
mission  management  software/hardware. 

The  lack  of  tramsparency  creates  a  need  for  changes 
in  the  network  components  or  a  need  for  user  education  in 
order  to  avoid  conflict  between  the  information  processing 
and  the  communication  portions  of  the  computer  network.  Most 
communication  protocols  have  a  problem  with  code  transparency. 
For  example,  some  protocol  may  not  allow  an  end-of-transmission 
code  to  be  used  within  the  text  of  a  message.  In  this  case, 
the  entire  message  must  be  scanned  and  modified  in  order  to 
remove  any  illegal  bit  sequences.  This  detection  and  modifi¬ 
cation  process,  which  may  be  hemdled  in  hardware  or  software, 
extends  the  length  of  the  n^ssage  and  reduces  the  information 
tremsfer  rate. 

9 .  Network  Security 

Network  security  is  another  totally  qualitative  term 
used  to  describe  the  degree  of  protection  provided  for  the 
information  handled  in  a  computer  network  from  unauthorized 
access.  The  importance  of  network  security,  of  course. 
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depends  on  the  sensitivity  of  the  information  being  handled. 
For  roost  military  and  governmental  networks,  security  is 
very  importemt. 

The  security  of  information  is  affected  by  the 
processing  2md  communication  devices,  the  treuismission 
facilities,  the  transmission  meuiagement  software/haurdware, 
the  terminal  station,  the  authorization  that  the  users  of  a 
terminal  station  have  to  use  it,  and  the  isolation  of  user's 
files  from  each  other.  Of  these  network  components,  the 
communication  devices,  the  transmission  facilities,  and 
the  transmission  management  software/hardware  are  the  most 
vulnereJale  to  the  unauthorized  access  of  information. 

The  most  effective  method  of  providing  information 
security  is  through  information  encryption.  Encryption  is 
best  applied  on  an  end-to-end  basis,  because  it  provides 
protection  over  the  full  length  of  the  message's  transmission 


SPECIFICATIONS  OF  THE  LAN  SIMULATION  MODEL 


A.  INTRODUCTION 


Martin  [Ref.  8]  defines  a  simvilation  model  to  be:  "a 
logical-mathematical  representation  of  a  concept,  system,  or 
operation  programmed  for  solution  on  a  high-speed  electronic 
computer."  A  simxilation  model  can  be  constructed  euid  applied 
during  any  phase  of  system  design  or  predesign  conceptualiza¬ 
tion.  It  depends  upon  the  desired  answers  eUbout  the  system 
to  decide  when  a  model  has  to  be  constructed.  Thus,  a  simu¬ 
lation  model  can  be  constructed  [Ref.  8] : 

1.  Before  the  system  is  designed  in  order  to  determine 
parameter  sensitivity  and  to  optimize  or  evaluate  the  system 
design. 

2.  During  the  system  design  phase  in  order  to  test  and 
experiment  with  system  design  concepts . 

3.  After  a  system  has  been  designed  and  built  in  order  to 
supplement  system  test  results  and  to  evaluate  overall  system 
effectiveness. 

The  SPLICE  project  at  the  Naval  Postgraduate  School, 
Monterey,  California,  is  now  in  the  predesign  phase  of  a 
Loca-  Area  Network  (LAN)  system.  This  thesis,  as  part  of 
the  project,  intends  to  support  the  design  of  a  LAN  imple¬ 
menting  the  SPLIC  functions,  by  discussing  in  this  chapter  the 
specifications  of  a  simulation  model  which  will  help  in 


pareuneter  sensitivity  analysis  and  LAN  design  optimization 
and  evaluation. 

1.  Background 

Simulation  models  have  been  widely  used  to  study 
performance  of  computer  systems.  In  the  area  of  computer 
networks  and  especially  of  LANs,  several  simulation  projects 
have  been  reported  recently  [Refs.  21,  22,  23]  but  they  tend 
to  place  emphasis  on  the  development  and  verification  of  the 
communication  and  access  protocols. 

With  respect  to  a  LAN  employing  a  bus  architecture, 
as  the  one  described  in  the  SPLICE  Request  for  Proposal  [Ref. 

2]  for  the  implementation  of  SPLICE  functions,  there  has  been 
little  work  done  on  the  modeling  of  such  a  network.  That 
is,  to  model  the  communication  system  as  well  as  the  functions 
of  the  nodes.  Tropper  [Ref.  21]  suggests  that:  "A  potentially 
effective  approach  to  the  modeling  of  such  a  system  would  be 
to  use  Jackson's  open  queueing  networks  to  model  the  nodes, 
and  to  use  the  appropriate  time-delay  formula  to  model  the 
performance  of  the  bus  itself." 

2 .  Overview 

Following  the  approach  proposed  by  Tropper  this  chap¬ 
ter  will  describe  a  Local  Area  Network  (LAN)  simulation  model 
as  an  open  queueing  network.  First,  the  simulation  model 
resources  are  described  in  terms  of  the  components  which  com¬ 
pose  the  model  LAN,  i.e.,  the  node  processor,  the  node-to- 
local  network  adaptor  (LNA)  interface,  the  LNA  communications 


software/hardware,  and  the  transmission  medixim.  Next,  how 
these  resources  are  modeled  as  an  open  network  of  queues  is 
described.  Then,  the  model  workload  is  defined  assuming  eui 
on-line  environment  with  different  classes  of  treuisactions . 
Finally,  the  transaction  flow  through  the  LAN  simulation 
model  and  the  selection  of  transaction  classes  are  described 
in  terms  of  the  stochastic  processes  representing  the  flow 
through  the  queueing  network. 

B.  SIMULATION  MODEL  RESOURCES 

The  simulation  model  resources  are  described  below  in 
terms  of  the  components  which  compose  the  LAN  model  depicted 
in  Figure  4.1.  For  that  particular  design  the  resources 
which  serve  user  transactions  and  contribute  to  delay  are 
the  following: 

1.  Node  Processor, 

2.  Node-to-Local  Network  Adaptor  (LNA)  Interface, 

3.  LNA  Communications  Software/Hardware, 

4.  Transmission  medium. 

The  resources  of  the  model  are  characterized  by  their 
capacity  to  service  requests,  where,  the  request  is  charac¬ 
terized  by  the  resource  capacity  it  consumes .  A  description 
of  each  resource  and  its  characteristics  follows. 

1.  Node  Processor 

A  node  processor  in  the  LAN  configuration  of  Figure 
4.1  can  be  a  Host  or  Front-End  Processor  (FEP)  or  a  processor 
implementing  one  or  more  SPLICE  functions  (e.g..  Terminal 
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Mgt. ,  Data  Base  Mgt.,  etc.  [Refs.  1,  19].  Each  node  contributes 
to  response  delay  by  having  to  process  applications  and  exe¬ 
cute  high-level  protocols  residing  in  the  node.  A  typical 
application  in  a  LAN  environment  with  a  delay  requirement  is 
a  query-response  activity  in  which  a  user  at  a  terminal 
connected  to  a  node  (FEP)  inputs  a  query  to  a  data  base 
that  resides  on  another  node.  Using  the  term  "application" 
in  general/  different  application  processes  reside  in  differ¬ 
ent  nodes  of  the  LAN  edong  with  nodal  communications  software. 

The  execution  of  applications  software  residing  in 
the  nodes  is  initiated  by  requests  from  users  at  terminals 
or  processes  in  other  nodes.  The  resources  which  are  con- 
svimed  in  the  execution  of  the  applications  and  nodal  communi¬ 
cations  software  can  be  characterized  by  the  following 
factors  representing  design  pareuneters  of  the  LAN: 

a.  Number  of  instructions  executed  (path  length) , 

b.  Node  processing  capacity, 

c.  Workload  mix. 

The  workload  mix  represents  the  concvurrent  tasks  which  are 
executed  in  addition  to  the  task  being  executed  [Ref.  24] . 

The  above  factors,  as  well  as  factors  characterizing  the 
other  model  resources  discussed  later,  will  be  used  as  user 
input  values  during  the  implementation  phase  of  the  LAN 
simulation  model. 

2.  Node-to-LNA  Interface 

The  node-tO’-LNA  interface  is  a  physical  serial  half¬ 
duplex  server.  However,  logically,  it  can  support  full 
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duplex  data  transfer.  It  can  be  characterized  by  delay 
components  with: 

a.  Waiting  time.. 

b.  Transmission  time, 

c.  Propagation  time. 

The  propagation  time  is  usually  negligible  since  the  distance 
between  the  nodes  and  LNA  is  typically  short.  The  waiting 
plus  the  transmission  time  is  a  function  of: 

a.  the  total  traffic  for  each  interface,  and 

b.  the  transfer  rate  of  the  interface. 

3.  LNA  Communications  Software/Hardware 

The  LNA  is  assumed  to  be  a  microcomputer-based  com¬ 
ponent  which  implements  the  data  link  layer.  The  protocol 
of  this  layer  which  resides  in  the  LNA  can  be  implemented 
in  software  or  hardware.  For  softw2Lre  implementation,  the 
LNA  is  characterized  by  the  same  factors  discussed  earlier  in 
applications  and  nodal  commtini  cat  ions  software.  For  the 
hardware  implementations,  the  associated  delay  is  character¬ 
ized  by  the  hardware  service  rate. 

4.  Transmission  Medium 

The  transmission  medium  serves  as  the  physical  connauni 
cation  path  in  the  LAN.  The  delay  associated  with  it  is 
characterized  by: 

a.  the  data  transfer  rate  of  the  treunsmission  media, 

b.  the  overhead  imposed  by  the  access  protocols, 


c.  the  distamce  between  nodes. 


As  it  was  stated  eaurlier,  all  the  characteristics 


of  the  LAN's  model  resources  which  ceui  be  coiisidered  as  de¬ 
sign  parameters  can  be  used  as  user  input  values  during  a 
simulation  run  in  order  to  evaluate  the  sensitivity  of 
different  performance  measures. 

C.  LAN  RESOURCES  MODELING 

This  section  describes  how  the  LAN  resources  specified 
earlier  are  modeled  as  an  open  network  of  queues.  Different 
kinds  of  processing  activities  performed  by  the  LAN  servers 
(i.e.,  the  node  processor,  the  node-to-LNA  interface,  the 
LNA  processor,  2md  the  transmission  medi\im)  ,  represent  the 
delay  components  of  the  network. 

The  queueing  network  which  represents  the  LAN  system  is 
decomposed  into  modules  corresponding  to  the  network  servers. 
For  each  module  the  classes  of  activities  with  their  priority 
the  assumptions  for  the  module,  the  delay  equations,  and  an 
overhead  factor  are  given  below.  The  models  for  each  of  the 
four  modules  are  specified  as  follows: 

1 .  Node  Processor  Modeling 

The  node  processor  can  be  modeled  as  a  single  re¬ 
source  multi-class  queuexng  system  with  a  preemptive- resume 
priority  service  discipline,  as  depicted  in  Figure  4.2. 
Concerning  a  SPLKZLAN  configuration  a  node  ceui  be  a  Front- 
End  Processor  (FEP) ,  a  Host  computer,  or  a  Mini-computer 
implementing  SPLICE  functions.  Each  of  these  nodes  includes 
Central  Processor  (CP)  and  dedicated  resources  (e.g..  Memory, 


Figure  4.2.  Node  Queueing  System 


Disks) .  The  delay  imposed  by  the  Disk  access  requirements 
must  be  included  during  a  simulation  run  for  calculating 
message  delay  and  response  time  of  any  transaction  processing 
Also  Disks  depend  upon  the  processor  to  handle  interrupts  for 
Disk  I/O.  This  demand  can  be  specified  in  the  model  as 
overhead  (NOH:  Node  Overhead)  to  the  node  processor.  This 
overhead,  which  also  includes  other  LAN  administrative  func¬ 
tions,  affects  the  nominal  capacity  of  the  node  processor. 

The  Node  Effective  Processing  Capacity  (NEPC)  is  given  [Ref. 
24]  by: 

NEPC  =  (1  -  NOH) NIPS, 

where  NIPS  (Node  Instructions  Per  Second)  is  the  average 
number  of  machine  instructions  per  second  that  the  node 
processor  can  execute. 

A  variety  of  activities  can  be  considered  for  each 
node.  In  the  LAN  simulation  model  five  classes  of  activities 
are  specified  which  are  serviced  on  a  preemptive- resume 
scheme  [Ref.  24].  These  activities  are: 

a.  Link- In:  Link  level  functions  for  messages  inbound 
from  the  local  LNA. 

b.  Link-Out:  Link  level  functions  for  messages  outbound 
from  the  node  to  the  local  LNA. 

c.  Protocols-In:  High  level  protocol  functions  for 
messages  inbound  from  the  local  LNA. 


d.  Protocols-Out :  High  level  protocol  functions  for 
messages  outbound  to  the  local  LNA. 

e.  Application:  Transaction  segment  processing. 

The  service  time  for  each  activity  c«m  be  character¬ 
ized  by  the  activity  path  length  in  machine  instructions  and 
the  effective  processor  capacity  (MEPC)  of  the  node  processor. 

A  priority  structure  for  servicing  the  five  classes 
of  activities  has  to  be  specified  for  every  node  in  the  LAN 
(FEP,  Host,  etc.) .  For  example,  the  priority  structure  for 
a  FEP  node  is  assumed  to  be  (from  highest  to  lowest) : 

a.  Protocols-Out 

b .  Link-Out 

c.  Application 

d.  Protocols-In 

e.  Link- In. 

This  priority  structure  is  independent  of  any  other 
priority  scheme  based  upon  the  type  of  transactions  emd  which 
will  affect  only  the  queue  discipline  of  class  of  activities. 

The  probable  transaction  priority  is  not  considered  here  to 
avoid  unnecessary  complexity  of  the  model. 

Assumptions  for  the  node  queueing  model  are  as  follows: 

a.  The  queueing  system  has  a  single  waiting  line  and  a 
single  server. 

b.  Each  class  of  activity  is  represented  by  an  independent 
Poisson  process  with  mean  arrival  rate 

c.  The  service  times  of  each  class  of  activity  is  represented 
by  an  exponential  distribution  with  mean  service  time  S^. 
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The  rationale  for  choosing  these  assunptions  con¬ 
cerning  arrival  of  classes  of  activities  and  service  times 
is  well  documented  [Refs.  25,  26,  27,  29]. 

The  equations  for  node  delay,  j '  various 

classes  of  activities  are  given  [Ref.  25]  by: 


2  2-1 
I  p.)  +  S.  X  1/(1-  1  p  ) 

i=l  ^  ^  i»l  ^ 


where  for  a  node  g  the  nvunber  of  activity  classes  is  j  and 
the  server  utilization  p^  *  The  X^'s  are  determined 

by  solving  the  balance  equations  for  the  network  of  queues 
associated  with  the  node  module. 

2.  Node-to-LNA  Interface  Modeling 

The  node-to-LNA  interface  can  be  modeled  as  a  single 
server  queue.  An  overhead  factor  (lOH:  Interface  OverHead) 
can  be  considered  on  the  nominal  transfer  rate  of  the  inter¬ 
face  for  non-data  bits.  Thus,  the  Effective  Transfer  Rate 
(ETR)  for  the  interface  is  given  by: 

ETR  »  (1  -  lOH)  ITR, 

where  ITR  is  the  nominal  Interface  Transfer  Rate  in  bits  per 
second  (bps) . 

Assumptions  for  the  interface  queueing  model  are  the 


following: 


a.  The  queueing  system  has  a  single  waiting  line  and  single 


server. 

b.  There  are  two  classes  of  arrivals  (messages  from  the 
node  to  the  LAN  emd  messages  from  the  LNA  to  the  node) 
without  priority  structure  (i.e.,  the  service  discipline  is 
First-Come,  First-Served) . 

c.  Each  arrival  class  is  represented  by  an  independent 
Poisson  process  with  parameter 

d.  The  service  time  of  each  arrival  class  is  represented 
by  an  exponential  distribution  with  mean  service  time 

The  equations  for  the  interface  delay  of  node  g  with 
j  arrival  classes,  are  given  [Ref.  24]  by; 

Tgj  *  PS/(1  -  P)  +  S^, 


where 


p  »  X  'S 

X '  »  ^1  ^  ^2 

S  =  +  X2S2)  X' 

3.  LNA  Processor  Modeling 

The  LNA  processor  can  be  modeled  as  a  single  resource, 
multi-class  queueing  system  with  a  preemptive-resume  priority 
structure  as  the  one  given  in  Figure  4.2.  An  overhead  factor 
(AOH:  Adaptor  OverHead)  can  be  considered  on  the  processing 


capacity  of  the  LNA  processor,  which  includes  system's  admin* 
istration  overhead  functions.  Thus,  the  effective  processing 
capacity  (AEPC:  Adaptor  Effective  Processing  Capacity)  for 
a  LNA  processor  is  given  by: 

AEPC  *  (1  -  AOH)  AIPS, 

where  AIPS  is  the  average  number  of  machine  instructions  per 
second  that  the  LNA  processor  can  execute. 

For  the  LNA  module  in  the  simulation  model  five 
classes  of  activities  can  be  specified.  A  list  of  these 
activities  follows  [Ref.  24] : 

a.  Network  Link-In:  Link  level  functions  for  messages 
inbound  to  the  LNA  from  the  network  transmission  medium. 

b.  Network  Link-Out:  Link  level  functions  for  messages 
outbound  from  the  LNA  to  the  network. 

c.  Node  Link-In:  Link  level  functions  for  messages 
inbound  to  the  LNA  from  the  node  side. 

d.  Node  Link-Out:  Link  level  functions  for  messages 
outbound  from  the  LNA  to  the  node. 

e.  Protocol:  Execution  of  data  link  protocol  for  messages 
from  the  network  side  and  the  node  side.  There  is  a  FCFS 
discipline  within  this  class  of  activity. 

The  priority  structure  of  classes  of  activities  for  a  LNA 
processor  is  assumed  to  be  (from  highest  to  lowest) : 

a.  Network  Link-Out 


b .  Node  Link-Out 


c.  Network  Link- In 


d.  Node  Link-In 

e .  Protocol 

Again  the  priority  structure  is  independent  of  any 
other  priority  scheme  which  can  be  imposed  at  trauisaction 
level . 

The  mathematical  assumptions  as  well  as  the  equations 
for  LNA  model  are  the  s^une  as  those  given  earlier  for  the 
node  model. 

4.  Trauismission  Medium  Modeling 

The  combination  of  the  physical  protocol  layer  of 
the  OSI  model  2Uid  the  transmission  medium  can  be  modeled  as 
a  single  server  queue.  The  physical  protocol  layer  is  imple¬ 
mented  in  hardware  and  is  referred  to  aa  the  Media  Access 
Unit  (MAU) .  The  transmission  medium  access  scheme  considered 
in  the  simulation  model  is  the  Carrier  Sense  Multiple  Access 
with  Collision  Detection  (CSMA/CD)  which  has  been  modeled 
extensively  [Ref.  21] . 

The  assumptions  for  the  queueing  analysis  of  the 
CSMA/CD  access  scheme  are  [Ref.  21] : 

a.  Poisson  arrivals  over  an  infinite  population. 

b.  Negligible  collision  detection  time  (compared  to  the 
bus  propagation  time) . 

c.  Chauinel  sensing  is  instantaneous. 

d.  Propagation  time  between  any  two  nodes  is  uniform  and 
equal  to  the  maximum  value. 
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e.  Retransmission  of  packets  is  ccording  to  the  Binary 
Exponential  Backoff  probability  rule. 

f.  The  rcuidom  interval  parameters  for  the  backoff  algorithm 
is  uniformly  distributed  ^uld  the  same  for  all  MAU's. 

A  priority  message  system  can  be  supported  at  the 
tr2msmission  medium  level  by  varying  each  MAU's  backoff 
algorithm  (assumptions  ”e"  and  "f"  above)  and  letting  some 
of  them  have  linear  instead  of  exponential  backoff  algorithm 
[Ref.  22] . 

An  algorithm  for  the  CSMA/CD  access  scheme  is  given 
[Ref.  24]  in  Figure  4.3. 

The  equation  for  the  time  delay,  D,  in  terms  of  the 
syst^  throughput,  the  offered  load,  and  other  system 
parameters  is  given  by  the  formula  [Ref.  26]: 

D  =  (Al  +  A2  +  A3)T 


where 

Al  -  the  normalized  wasted  time  due  to  collisions, 

A2  s  the  dead  time  due  to  retransmissions  and 
rescheduling , 

A3  >  the  propagation  and  transmission  time,  and 
T  »  the  packet  length. 


Given  that: 


NO 
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Figure  4.3.  CSMA/CD  Algorithm 
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N1  »  the  average  number  of  times  a  packet  encounters 
a  collision  or  btisy  state, 

N2  -  the  average  number  of  times  a  packet  encounters 
a  collision, 

R1  »  the  normalized  mean  retrial  interval  after 

detecting  a  busy  condition, 

R2  s  the  normalized  mean  retrial  interval  after 
detecting  a  collision, 

a  =  the  progagation  delay, 

G  =  the  offered  channel  traffic  (load)  ,  euid 
S  -  the  throughput. 

It  follows  that: 

A1  =  N2(W  +  a) 

N,+l 

A2  »  R2(2  ^  -  1)  +  (N1  -  N2)R1 

A3  =  a  +  1 

where : 

W  »  (1  -  e"®®)/G  -  ae”^*^ 

N1  =  G/S  -  1 

N2  »  (1  -  aG)  e"*^  -  1 

and  the  normalized  throughout  (S  =  XT)  is  related  to  the 
normalized  offered  packet  traffic  (including  retransmissions) 
G,  by  the  equation  [Ref.  27]; 


C.  MODEL  WOKKLQAD 

For  the  partlculeu:  LAM  configuration  to  be  modeled 
(Figure  4.1),  the  network  user's  transactions,  when  trans¬ 
lated  into  access  and  processing  requirements,  can  be  charac¬ 
terized  by  the  type  and  the  amount  of  system  resources  the 
network  will  have  to  provide  in  order  to  fulfill  these  re¬ 
quirements.  The  sum  of  system  resource  requirements  gener¬ 
ated  by  all  the  network  users  represents  the  system  or 
network  workload.  Gener2d.ly,  the  workload  of  a  computer 
system  has  certain  basic  statistical  characteristics  that 
do  not  change  greatly  over  short  periods  of  time.  The  use  of 
such  characteristics  make  it  possible  to  do  the  following 
[Ref.  28] : 

1.  To  characterize  the  system  workload  by  statistical 
distributions  of  requirements  placed  on  individual  system 
resources ,  and 

2.  To  define  a  unit  of  work  and  then  express  the  workload 
characteristics  in  relation  to  this  unit. 

The  workload  characterization  of  a  SPLICE  LAM  configura¬ 
tion  would  be  based  on  an  on-line  and  batch  input  environ¬ 
ments.  The  simulation  model  specified  in  this  chapter 
considers  an  on-line  environment  with  twelve  different 
classes  of  trauisactions  [Ref.  2].  This  is  because  it  was 
felt  that  to  include  the  batch  input  environment  added  detail 
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and  complexity  to  the  simiilation  model  which  was  unnecessary 
for  the  fulfillment  of  analysis  dajectives  during  the  early 
stages  of  SPLICE  LAN  design. 

Each  class  of  transaction  requires  service  from  resources 
of  one  or  more  network  nodes  emd  is  divided  into  a  nuxdder 
of  transaction  segments  (processes) .  A  description  of  what 
constitutes  a  tramsaction  class  and  how  the  on-line  workload 
is  specified  follows. 

1.  Transaction  Class 

The  transactions  input  from  the  terminals  at  the  FEP 
node  of  the  LAN  are  described  as  a  series  of  transaction 
classes.  A  transaction  can  be  characterized  according  to 
its  arrival  rate  which  cem  be  converted  into  probability  of 
occurrence  or  cumulative  probability  of  occurrence,  and  the 
number  of  LAN  node  requests  (data  path)  it  requires.  For 
example,  suppose  the  LAN  contains  five  nodes.  Table  4.1 
shows  the  twelve  transaction  classes  and  their  hypothetical 
arrival  rates,  probabilities  of  occurrence,  and  node  re¬ 
quests.  For  example,  transaction  class  TC2  describes  those 
transactions  which  require  three  node  requests  (i.e.,  data 
path  used  1-2-5) .  The  data  path  is  determined  from  the  re¬ 
quired  LAN  resources  by  the  segments  (processes)  of  this 
transaction  class.  The  probability  of  such  a  transaction  (TC2) 
to  occur  in  the  transaction  input  stream  of  node  #1  (FEP)  is 
five  percent. 


TABLE  4.1 


On-Line  Workload  Characterization 
(Hypothetical  Data) 


TBMlSACnON 

CLASS 

BBAK  HOUR 
TRANSACnOM 
ARRIVAL  was 
(TRms/SBa 

PRCB^eiLnY 

CP 

OOCORFENCS 

OMILATIVE 

PROBffilUaY 

OF 

OGCURFCNCE 

UN  NOCE 
BEQUEST 
(NOEE- 
NUBBER) 

TCI 

3.07888 

0.17 

0.17 

1-2 

TC2 

0.88445 

0.05 

0.22 

1-2-5 

TC3 

0.59364 

0.03 

0.25 

1-3-5 

TC4 

0.41312 

0.02 

0.27 

1-2-3-5 

TC5 

1.58868 

0.09 

0.36 

1-3-4 

TC6 

1.95634 

0.11 

0.47 

1-2-3-4 

TC7 

0.71295 

0.04 

0.51 

1-3-4-5 

TC8 

0.84101 

0.05 

0.56 

1-2-3-4-5 

TC9 

0.28638 

0.02 

0.58 

1-4-5 

TCIO 

1.42839 

0.08 

0.66 

1-2-4-5 

TCll 

0.60543 

0.03 

0.69 

1-2-3 

TC12 

5.64292 

0.31 

1.00 

1-2-4 

2.  Transaction  Segment 

Each  class  of  transaction  is  composed  of  a  series  of 
transaction  segments.  These  segments  are  small  units  of 
work  within  a  transaction  which  compete  for  LAN  resources. 
Reference  (2)  recognizes  eight  types  of  transaction  segments, 
the  following: 

a.  Edit 

b .  Validation  read 

c.  Validation 


d.  Error  message 


e.  Processing  read 
£.  Processing 

g.  File  write 

h .  Format  output . 

The  process  load  for  each  transaction  class  along 
with  their  segments  characteristics  and  corresponding  hypo¬ 
thetical  values  are  given  in  T2d>les  4.2  through  4.13.  It 
can  be  seen  that  a  tramsaction  class  is  divided  into  four  to 
eight  segments  with  different  message  length/  char2LCteris- 
tics/  and  processing  requirements  for  each. 

E.  TRANSACTION  FLOW 

A  transaction  flow  through  the  LAN  system  simulation  model 
is  a  flow  through  the  network  of  queues/  each  modeling  one 
resource  of  the  system  model.  The  queueing  network  which 
represents  the  LAN  system/  as  it  was  discussed  earlier/  is 
not  considered  and  modeled  as  a  whole/  but  it  is  decomposed 
into  modules  which  are  analyzed  in  isolation.  The  focus  in 
this  approach  is  on  the  stochastic  processes  representing 
the  flow  through  each  module  where  the  output  of  one  module 
represents  the  input  to  a  subsequent  module. 

The  flow  in  the  simulation  model  can  be  portrayed  as  a 
series  of  discrete  events.  The  occurrence  or  timing  of  these 
events  is  on  a  next  event  scheduled  basis.  The  next  event 
approach  to  simulation  is  discussed  briefly  by  Fishman  [Ref. 

6] .  Also  the  occurrence  of  events  is  governed  according  to 
the  variovis  statistical  distributions  of  requirements  which 


TABLE  4.2 


Process  Load  for  Transaction  Class  1 


TRANSACTION 

SEGMENT _ CHARACTERISTICS  VALUE 


1. 

Edit 

a. 

Message  length 

2 

b. 

No.  of  instructions 

40 

c. 

%  of  fail 

1 

2. 

Validation 

a. 

No .  of  records 

1 

read 

b. 

Record  length 

1500 

c. 

No.  of  instructions 

per  access 

5 

d. 

%  of  fail 

0 

3. 

Validation 

a. 

No .  of  instructions 

0 

b. 

%  of  fail 

0 

4. 

Error  Mag 

a. 

No.  of  instructions 

5 

b. 

Message  length 

80 

5. 

Processing 

a. 

No.  of  records 

0 

read 

b. 

Record  length 

0 

c. 

No.  of  instructions 

0 

6. 

Processing 

a. 

No.  of  instructions 

0 

7. 

File  write 

a. 

No.  of  instructions 

0 

b. 

No.  of  modified  record 

0 

c. 

Length  of  modified  record 

0 

d. 

No .  of  adds 

0 

e. 

Length  of  added  record 

0 

f . 

No.  of  indices 

0 

8. 

Format  output 

a. 

No .  of  instructions 

5 

b. 

Message  Length 

1500 

c. 

No .  of  records 

1 
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TABLE  4.3 

Load  for  Tr2msaction  Claiss  2 

TRANSACTION 

SEGMENT 

CHARACTERIST  ICS 

VALUE 

Edit 


Validation 

read 


Validation 


Error  Msg 


Processing 

read 


Processing 
File  write 


Format  output 


Message  length 
Mo.  of  instructions 
%  of  fail 

Mo.  of  records 
Record  length 
Mo.  of  instructions 
per  access 
%  of  fail 

Mo.  of  instructions 
%  of  fail 

Mo.  of  instructions 
Message  length 

Mo.  of  records 
Record  length 
Mo.  of  instructions 

Mo.  of  instructions 

Mo.  of  instructions 
Mo.  of  modified  record 
Length  of  modified  record 
Mo.  of  adds 

Length  of  added  record 
No.  of  indices 

No.  of  instructions 
Message  length 
Mo .  of  records 


2^ 


TABLE  4.4 

Process  Load  for  Transaction  Class  3 


TRANSACTION 

SEGMENT 


CHARACTERISTICS 


VALUE 


Edit 

a. 

Message  length 

b. 

No.  of  instructions 

c. 

%  of  fail 

Validation 

a. 

No.  of  records 

read 

b. 

Itecord  length 

c. 

No.  of  instructions 
per  access 

d. 

%  of  fail 

Validation 

a. 

No.  of  instructions 

b. 

%  of  fail 

Error  Msg 

a. 

No.  of  instructions 

b. 

Message  length 

Processing  read 

a. 

No.  of  records 

b. 

Record  length 

c. 

No.  of  instructions 

Processing 

a. 

No.  of  instructions 

File  write 

a. 

No.  of  instructions 

b. 

No.  of  modified  record 

c. 

Length  of  modified  record 

d. 

No.  of  adds 

e. 

Length  of  added  record 

f . 

No.  of  indices 

Format  output 

a. 

No.  of  instructions 

b. 

Message  length 

c. 

No.  of  records 

TABLE  4.5 


Process  Load  for  Transaction  Class  4 


TRANSACTION 

SEGMENT  _  CHARACTERISTICS  _  VALOE 


1. 

Edit 

a. 

Message  length 

b. 

Mo.  of  instructions 

100 

c. 

%  of  fail 

1 

2. 

Validation 

a. 

No.  of  records 

1 

read 

b. 

Record  length 

c. 

No.  of  instructions 
per  access 

10 

d. 

%  of  fail 

1 

3. 

Validation 

a. 

No.  of  instructions 

b. 

%  of  fail 

1 

4. 

Error  Msg 

a. 

Mo.  of  instructions 

b. 

Message  length 

5. 

Processing 

a. 

No.  of  records 

read 

b. 

Record  length 

0 

c. 

No.  of  instructions 

0 

6. 

Processing 

a. 

No.  of  instructions 

0 

7. 

File  write 

a. 

No.  of  instructions 

20 

b. 

No.  of  modified  record 

0 

c. 

Length  of  modified  record 

0 

d. 

No.  of  adds 

1 

e. 

Length  of  added  record 

100 

f. 

No.  of  indices 

5 

8. 

Format  output 

a. 

No.  of  instructions 

b. 

Message  length 

c. 

No.  of  records 

1 

o  o  o  H  o  m 


TABLE  4.6 


Process  Load  for  Transaction  Class  5 


TRANSACTION 

SEGMENT 


CHARACTERISTICS 


VALUE 


Edit 

a. 

Message  length 

b. 

No .  of  instructions 

c. 

%  of  fail 

Validation 

a. 

No .  of  records 

read 

b. 

Record  length 

c. 

No.  of  instructions 
per  access 

d. 

%  of  fail 

Validation 

a. 

No .  of  instructions 

b. 

%  of  fail 

Error  Msg 

a. 

No.  of  instructions 

b. 

Message  length 

Processing 

a. 

No.  of  records 

read 

b. 

Record  length 

c. 

No.  of  instructions 

Processing 

a. 

No.  of  instructions 

File  write 

a. 

No.  of  instructions 

b. 

No.  of  modified  record 

c. 

Length  of  modified  record 

d. 

No.  of  adds 

e. 

Length  of  added  record 

f . 

No.  of  indices 

Format  output 

a. 

No.  of  instructions 

b. 

Message  length 

c. 

No.  of  records 

-.1  -  ^  •.  *.  v^-.•  •• .  -,  • . 


TABLE  4.7 

Process  Load  for  Transaction  Class  6 


TBANSACTION 

SEGMENT 


CHABACTERISTICS 


VALUE 


Edit 

a. 

Message 

length 

800 

b. 

No.  of 

instructions 

250 

c. 

%  of  fail 

8 

Validation 

a. 

No.  of 

records 

20 

read 

b. 

Record 

length 

350 

c. 

No.  of 

instructions 

per  access 

30 

d. 

%  of  fail 

3 

Validation 

a. 

No.  of 

instructions 

b. 

%  of  fail 

2 

Error  Msg 

a. 

No.  of 

instructions 

50 

b. 

Message 

length 

■H 

Processing 

a. 

No.  of 

records 

10 

read 

b. 

Record  length 

350 

c. 

No.  of 

instructions 

20 

Processing 

a. 

No.  of 

instructions 

250 

File  write 

a. 

No.  of 

instructions 

30 

b. 

No.  of 

modified  record 

15 

c. 

Length 

of  modified  record 

250 

d. 

No.  of 

adds 

15 

e. 

Length 

of  added  record 

350 

f. 

No.  of 

indices 

10 

Foxnnat  output 

a. 

No.  of 

instructions 

50 

b. 

Message  length 

c. 

No.  of 

records 

1 

TABLE  4.8 


Process  Load  for  Transaction  Class  7 


TRANSACTION 

SEGMENT 


CHARACTERISTICS 


VALUE 


Edit 

a. 

Message  length 

b. 

No.  of  instructions 

c. 

%  of  fail 

Validation 

a. 

No.  of  records 

read 

b. 

Record  length 

c. 

No.  of  instructions 
per  access 

d. 

%  of  fail 

Validation 

a. 

No.  of  instructions 

b. 

%  of  fail 

Error  Msg 

a. 

No.  of  instructions 

b. 

Message  length 

Processing 

a. 

Mo.  of  records 

read 

b. 

Record  length 

c. 

No.  of  instructions 

Processing 

a. 

No.  of  instructions 

File  write 

a. 

No.  of  instructions 

b . 

No.  of  modified  record 

Length  of  modified  record 
No.  of  adds 

Length  of  added  record 
No.  of  indices 


Format  output 


a.  No.  of  instructions 

b.  Message  length 

c.  No.  of  records 


5k 


TABLE  4.9 


Process  Load  for  Transaction  Class  8 


TRANSACTION 

SEGMENT 


CHARACTERISTICS 


VALUE 


Edit 

a. 

Message  length 

b. 

No.  of  instructions 

c. 

%  of  fail 

Validation 

a. 

No.  of  records 

read 

b. 

Record  length 

c. 

No.  of  instructions 
per  access 

d. 

%  of  fail 

Validation 

a. 

No.  of  instructions 

b. 

%  of  fail 

Error  Msg 

a. 

No.  of  instructions 

b. 

Message  length 

Processing 

a. 

No.  of  records 

read 

b. 

Record  length 

c. 

No.  of  instructions 

Processing 

a. 

No.  of  instructions 

File  write 

a. 

No.  of  instructions 

b. 

No.  of  modified  record 

c. 

Length  of  modified  record 

d. 

No.  of  adds 

e. 

Length  of  added  record 

f . 

No.  of  indices 

Format  output 

a. 

No.  of  instructions 

b. 

Message  length 

c. 

No.  of  records 

TABLE  4.10 


Process  Load  for  Tremsaction  Class  9 


TRANSACTION 

SEGMENT  _ CHARACTERISTICS  _ VALUE 


1. 

Edit 

a. 

Message  length 

30 

b. 

No.  of  instructions 

300 

c. 

%  of  fail 

2 

2. 

Validation 

a. 

No.  of  records 

5 

read 

b. 

Record  length 

150 

c. 

No.  of  instructions 

per  access 

20 

d. 

%  of  fail 

3 

3. 

Validation 

a. 

No.  of  instructions 

300 

b. 

%  of  fail 

2 

4. 

Error  Msg 

a. 

No.  of  instructions 

100 

b. 

Message  length 

80 

5. 

Processing 

a. 

No.  of  records 

100 

read 

b. 

Record  length 

300 

c. 

No.  of  instructions 

5 

6. 

Processing 

a. 

No.  of  instructions 

500 

7. 

File  write 

a. 

No.  of  instructions 

20 

b. 

No.  of  modified  record 

200 

c. 

Length  of  modified  record 

100 

d. 

No.  of  adds 

100 

e . 

Length  of  added  record 

200 

f . 

No.  of  indices 

4 

8. 

Format  output 

a. 

No.  of  instructions 

50 

b. 

Message  length 

132 

c. 

No.  of  records 

400 

TABLE  4.11 


Process  Load  for  Transaction  Class  10 


TRANSACTION 

SEGMENT  CHARACTERISTICS _ _ VALUE 


1. 

Edit 

a. 

Message  length 

800 

b. 

No.  of  instructions 

300 

c. 

%  of  fail 

10 

2. 

Validation 

a. 

No .  of  records 

20 

read 

b. 

Record  length 

350 

c. 

No.  of  instructions 

per  access 

30 

d. 

%  of  fail 

3 

3. 

Validation 

a. 

No.  of  instructions 

500 

b . 

%  of  fail 

2 

4. 

Error  Msg 

a. 

No .  of  instructions 

50 

b. 

Message  length 

1500 

5. 

Processing 

a. 

No.  of  records 

10 

read 

b. 

Record  length 

350 

c. 

No.  of  instructions 

20 

6. 

Processing 

a. 

No.  of  instructions 

250 

7. 

File  write 

a. 

No.  of  instructions 

30 

b. 

No.  of  modified  record 

20 

c. 

Length  of  modified  record 

350 

d. 

No.  of  adds 

0 

e. 

Length  of  added  record 

0 

f . 

No.  of  indices 

0 

8. 

Format  output 

a. 

No.  of  instructions 

50 

b. 

Message  length 

1500 

c. 

No.  of  records 

1 
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TABLE  4.12 

Load  for  Transaction  Class  11 

TRANSACTION 

SEGMENT 

CHARACTERISTICS 

VALUE 

Edit 


a.  Message  length 

b.  Mo.  of  instructions 

c.  %  of  fail 


Validation 

read 


Validation 


Error  Msg 


Processing 

read 


Processing 
File  write 


Format  output 


No.  of  records 
Record  length 
Mo.  of  instructions 
per  access 
%  of  fail 

Mo.  of  instructions 
%  of  fail 

Mo.  of  instructions 
Message  length 

Mo.  of  records 
Record  length 
Mo.  of  instructions 

No.  of  instructions 

No.  of  instructions 
Mo.  of  modified  record 
Length  of  modified  record 
Mo.  of  adds 

Length  of  added  record 
No.  of  indices 

Mo.  of  instructions 
Message  length 
No.  of  records 


TABLE  4.13 


Process  Load  for  Treuis action  Class  12 


TRANSACTION 

SEQiENT _ CHARACTERIST ICS  _  _ VALUE 


1. 

Edit 

a. 

Message  length 

80 

b. 

No.  of  instructions 

10 

c. 

%  of  fail 

1 

2. 

Validation 

a. 

No .  of  records 

0 

read 

b. 

Record  length 

0 

c. 

No.  of  instructions 

per  access 

0 

d. 

%  of  fail 

0 

3. 

Validation 

a. 

No.  of  instructions 

0 

b. 

%  of  fail 

0 

4. 

Error  Msg 

a. 

No.  of  instructions 

35 

b. 

Message  length 

150 

5. 

Processing 

a. 

No.  of  records 

1 

read 

b. 

Record  length 

80 

c. 

No.  of  instructions 

10 

6. 

Processing 

a. 

No.  of  instructions 

7. 

File  write 

a. 

No.  of  instructions 

10 

b. 

No.  of  modified  record 

0 

c. 

Length  of  modified  record 

0 

d. 

No.  of  adds 

1 

e. 

Length  of  added  record 

80 

f . 

No.  of  indices 

2 

8. 

Format  output 

a. 

No.  of  instructions 

20 

b. 

Message  length 

80 

c. 

No.  of  records 

1 
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are  placed  on  individual  system  resources.  This  section  will 
discuss  transaction  flow  within  the  simulation  model  in 
terms  of  transaction  class  selection  and  processing. 

1.  Transaction  Class  Selection 

The  selection  emd  processing  of  a  tremsaction  in¬ 
volves  the  determination  of  its  class  and  consequently  the 
tr2msaction  segments  needed,  each  with  their  specific 
processing  requirements. 

The  arrival  of  transactions  at  their  initial  input 
into  the  front-end  processor  can  be  characterized  by  a 
Poisson  process,  assuming  independent  and  rauidom  inputs. 

Then  it  can  be  shown  [Ref.  29]  that  the  transaction  inter¬ 
arrival  times  (Tj^)  are  exponentially  distributed  about  a 
mean  interarrival  time.  This  distribution  is  described  by 

P(s)  »  P(t^<,S)  »  1  -  e“^®,  S  ^  0 

where : 

P(S)  »  the  probability  that  a  transaction  will 
arrive  within  time  S. 

A  *  the  transaction  arrival  rate  at  the 
particular  processor. 

Since  the  tremsactions  are  assumed  to  enter  the  processor's 
input  queue  independently  and  at  reundom,  P(S)  must  be  a 
random  number  between  0  euid  1.  Consequently,  1-P{S)  is  a 
random  number  R.  Thus, 
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P(S) 


or 

=  1  -  PCS)  =  R 

or 

-AS  =  In  R 

or 

S  »  -  In  R/X 

where  S  is  the  time  increment  added  to  the  present  time  to 
schedule  the  arrival  of  the  next  treuisaction  at  the  Front- 
End  Processor  (FEP) . 

The  class  of  the  treuisaction  input  at  the  FEP  is 
determined  by  referring  to  their  cumulative  probability  of 
occiirrence  (Table  4.1)  according  to  a  step  probability 
function.  This  fiinction  allows  for  the  independent  random 
selection  of  transaction  class  while  maintains  their  relative 
probabilities  of  occurrence. 

After  a  transaction  has  been  assigned  a  class,  the 
corresponding  segments  (Tables  4.2  through  4.13}  of  this 
transaction  begin  processing  following  the  predetermined 
data  path  specified  in  Table  4.1  (LAN  node  requests). 
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When  all  of  the  node  requests  of  a  p^u:ticular  trans¬ 
action  have  con^leted  processing,  the  various  statistics 
associated  with  the  transaction  and  the  LAN  system  model  are 
accinniilated  and  updated  respectively  and  the  transaction  is 
output  from  the  model. 


IMPLEMENTATION  OF  THE  SIMULATION  MODEL 


The  three  general  phases  in  the  construction  of  a  simu¬ 
lation  model  are:  conceptualization  (specifications) , 
implementation,  £md  finally  execution  of  the  production  runs 
on  the  con^uter  with  interpretation  emd  evaluation  of  simu¬ 
lation  outcomes.  The  conceptualization  of  the  model  was 
discussed  in  the  previous  chapter,  where  the  specifications 
of  a  simulation  model  for  a  local  area  network  were  given. 
The  implementation  phase  involves  the  transformation  of 
conceptual  model  into  a  tangible  computer  simulation  that  is 
ready  to  generate  simulation  outputs  during  the  final  pheise 
of  the  construction. 

It  is  beyond  the  scope  of  this  thesis  to  implement  and 
conduct  experiments  with  the  specified  model.  However,  some 
comments  on  aspects  of  the  last  two  phases  of  model  construe 
tion  is  considered  essential  for  an  overall  presentation 
and  understanding  of  a  simulation  model.  This  chapter  will 
briefly  discuss  programming  of  the  model  in  terms  of  simula¬ 
tion  languages  available,  and  will  comment  on  simulation 
experiments . 

A.  PROGRAMMING  THE  MODEL 

Programming  is  one  of  the  major  tasks  in  the  implementa¬ 
tion  phase  of  model  construction.  It  includes  all  the  pro¬ 
cedures  required  to  treuisform  the  logical  statements  and 


mathematical  formulations  of  the  model  to  some  computer 
langtiage  statements.  Martin  [Sef.  8]  recognizes  the  follow¬ 
ing  procedures  to  be  involved  in  a  programming  task: 

1.  Modularization  of  the  model  in  a  programming  context 
in  which  the  model  is  subdivided  into  logical  units  and 
subunits. 

2.  Construction  of  flow  chart  diagrams  that  represent 
the  program  flow  of  the  model. 

3.  Coding  of  the  program  for  the  particular  computer. 

4.  Checking  the  validity  of  the  program  and  making 
necessary  revisions. 

5.  Preparation  of  input  and  output  formats. 

A  major  step  before  starting  actual  programming  is  the 
determination  of  a  computer  system  to  be  used  for  implemen¬ 
tation  of  the  model.  For  the  particular  LAN  simulation  model, 
specified  in  Chapter  IV  as  part  of  the  SPLICE  project  at  the 
Naval  Postgraduate  School,  it  would  be  implemented  using  the 
facilities  available  at  the  school,  i.e.,  IBM  3033  computer 
system  amd  GPSS  (General  Purpose  Systems  Simulator)  or 
SIMSCRIPT  simulation  languages.  Simulation  languages,  as 
distinguished  from  general-purpose  languages,  are  problem 
oriented.  Such  lamguages  are  usually  written  in  a  largely 
computer  independent  notation  for  a  particular  problem  area, 
and  contain  statements  or  constructs  appropriate  for  formu¬ 
lating  solutions  to  specific  types  of  problems.  Of  course 
general-purpose  languages  such  as  FORTRAN  can  be  used  in 
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simulation  modeling,  but  the  simulation  lemguages  designed 
specifically  for  the  purpose  of  computer  simulation  provide 
certain  useful  feat;ires  [Ref.  3]  .  Among  them: 

1.  Reducing  the  programming  task  and  providing  conceptual 
guid6uice . 

2.  Aiding  in  defining  the  classes  of  entities  within  the 
sysem  and  providing  flexibility  for  change. 

3.  Describing  the  relationship  of  entities  to  one  another 
and  to  their  common  environment. 

Various  simulation  languages  are  operational  at  the 
present  time.  The  most  popular  are  GPSS,  a  process-oriented 
lauigxiage,  and  SIMSCRIPT,  an  event-oriented  lemguage,  both 
available  at  NPS's  Computer  Center.  Table  5.1  gives  a  com¬ 
parative  list  of  some  features  of  GPSS  and  SIMSCRIPT  as 
briefly  summarised  by  Tocher  [Ref.  30].  Each  language  has 
certain  characteristics  and  applications ,  and  each  of  them 
can  be  extremely  useful  when  applied  properly.  A  brief 
description  of  each  of  these  two  simulation  languages  is 
given  below: 

1.  GPSS  Simulation  Language 

General  Purpose  Systems  Simulator  (GPSS) ,  was  developed 
originally  by  G.  Gordon  at  IBM  and  is  one  of  the  most  popular 
discrete-event  simulation  l2mguages.  GPSS  is  process  oriented, 
containing  a  supply  of  flow  chart- like  blocks  [Ref.  31] .  It 
also  provides  a  large  variety  of  autonomously  generated 
measurements  about  the  simulated  model .  GPSS  can  also  be 
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TABLE  5.1 


Features  of  6PSS  and  SIMSCRIPT 


GPSS 

SIMSCRIPT 

What  are  the  dominant  types 
of  activities? 

Transaction 

Tr^msaction 

How  is  the  system  repre¬ 
sented? 

Flow  chart 

FORTRAM-based 

What  uniform  random 
number  generation 
tedinique  is  used? 

Multiplicative  Multiplicative 

How  many  reuidom  number 
generators  are  available? 

Indefinite 

1 

Is  there  uniform  sampling? 

Yes 

Yes 

Is  there  any  statistical 
collecting  in  histogram 
form? 

Yes 

No 

Can  the  mean  be  confuted? 

Yes 

Yes 

Can  the  standard 
deviation  be 
computed? 

Yes 

Yes 

What  is  the  limit  on 
the  number  of 
distributions  ? 

100 

None 

Can  arithmetic  tests 
be  performed? 

Yes 

Yes 

Can  set  inclusion 
tests  be  performed? 

No 

Yes 

viewed  as  a  program  that  employs  a  language  which  is  de¬ 
signed  to  describe  simulation  models  of  a  system.  The  user 
constructs  a  logical  model  of  the  system  using  a  block 
diagraun  consisting  of  specific  block  types  in  which  each 
block  type  represents  some  basic  system  action. 

GPSS  elements  are  blocks,  trauisactions,  and  equip¬ 
ment.  Specific  block  types  have  a  name,  a  characteristic 
symbol,  and  a  block  number.  Each  block  has  a  designated 
block  time  that  indicates  the  niunber  of  time  units  required 
for  action  represented  by  the  block.  The  block  time  is  not 
constamt;  it  may  vary  in  a  random  or  nonrandom  manner. 
Transactions  are  basic  units  that  move  through  the  system. 
Equipment  elements  contain  facilities  amd  stores.  Facilities 
cam  handle  one  transaction  at  a  time,  whereas  stores  can 
hamdle  many  transactions  simultaneously. 

Since  its  original  version,  GPSS  has  appeared  in 
subsequent,  more  powerful  versions:  GPSS-II,  -III,  -IV,  -V, 
and  -360.  Cxirrent  versions  provide  limited  capability  for 
using  FORTRAN  subroutines.  Also  there  is  a  version  which 
through  a  CRT  display  unit,  provides  conversational  features, 
user  interactive  input ,  and  control . 

2 .  SIMSCRIPT  Simulation  Language 

SIMSCRIPT  was  developed  by  H.  Markowitz,  G.  Hausner, 
and  H.  Karr  at  the  RAND  Corporation.  It  was  one  of  the 
original  discrete-event  simulation  languages,  i.e.,  is  based 
upon  the  notion  that  every  model  system  is  composed  of 


elements  with  numerical  values  that  are  subject  to  periodic 
change.  The  state  of  a  system  is  described  in  terms  of 
entities,  attributes,  and  sets.  The  status  of  a  system  is 
changed  at  discrete  points  in  simulated  time  by  the  occur-* 
rence  of  an  event.  Entities  are  objects  which  compose  the 
system,  amd  may  be  classified  as  temporary  or  permanent  during 
the  simulation.  Attributes  are  properties  associated  with 
entities  or  items  that  describe  entities.  Sets  are  groups 
of  entities.  Status  is  the  niimerical  description  of  the  simu¬ 
lated  system.  Events  are  series  of  statements  grouped  to¬ 
gether  which  modify  the  status  of  the  simulated  system  at 
various  points  in  simulated  time.  There  are  two  types  of 
events  possible:  exogenous  (from  outside  the  simulation  sys¬ 
tem)  ,  and  endogenous  (from  within  the  simulation  system). 

The  occurrence  of  these  events  is  governed  by  a  SIMSCRIPT 
provided  timing  routine.  This  timing  routine  automatically 
keeps  track  of  simulated  time  emd  causes  the  various  events 
to  occur  as  they  are  scheduled  by  the  simulation  program. 

The  different  kinds  of  events  are  enumerated  in  an  events 
list  and  a  separate  event  subroutine  has  to  be  written  for 
each  event.  By  contrast  with  GPSS,  SIMSCRIPT  does  not 
provide  for  any  automatic  statistical  analysis. 

B.  SIMULATION  EXPERIMENTS 

The  final  phase  in  the  development  of  the  local  area  net¬ 
work  simulation  model  is  to  conduct  a  series  of  simulation 
experiments  which  will  be  helpful  in  drawing  conclusions  about 


the  system  modeled.  That  is,  for  the  peurticular  SPLICE  LAN 
design,  potential  bottlenecks  and  other  design  weaknesses 
can  be  identified  as  well  as  determining  the  adequacy  of  the 
components  of  the  design  relative  to  specific  delay  require¬ 
ments  . 

In  general,  simulation  experiments  are  conducted  for  a 
wide  variety  of  pvirposes,  some  of  which  are  the  following 
[Ref.  3]  : 

1.  Evaluation;  determining  if  a  proposed  system  design 
performs  well  in  an  absolute  sense  when  evaluated  against 
specific  criteria. 

2.  Comparison:  comparing  competitive  systems  designed  to 
carry  out  a  specified  function,  or  comparing  several  pro¬ 
posed  operating  policies  or  procedures. 

3.  Prediction;  estimating  the  performance  of  the  system 
under  some  projected  set  of  conditions. 

4.  Sensitivity  analysis:  determining  which  are  the  most 
significant  factors  affecting  overall  system  performance. 

5.  Optimization;  determining  exactly  which  combination 
of  factor  levels  will  produce  the  best  overall  response  of 
the  system. 

In  the  experimentation  phase  of  model  construction  sys¬ 
tem  performance  criteria  must  be  established  that  will  be 
used  in  rating  various  alternative  local  area  network  designs 
A  frequently  employed  performeuice  measure  in  most  local  area 
network  simulation  studies  is  time  delay  versus  throughput 


trade-off. 
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VI.  CONCLUSIONS 


The  specifications  of  a  Local  Area  Network  (LAN)  simu¬ 
lation  model  have  been  given.  The  model  is  specified  to 
allow  the  evaluation  of  alternative  network  designs  through 
either  modifying  the  workload  presented  to  the  network  or 
modifying  the  network  configuration. 

The  level  of  system  resolution  to  be  represented  in  the 
model  as  well  as  how  detailed  must  the  model  be  to  give  a 
valid  representation  of  the  system  depends  on  the  questions 
to  be  eisked  of  the  model.  The  more  complex  a  model  becomes 
the  less  able  it  is  to  answer  new  and  unexpected  questions. 
For  the  particular  SPLICE  LAN  design  in  its  present  state 
of  development  it  is  felt  the  simulation  model  is  adequate 
for  obtaining  a  basic  understemding  of  network  performance. 

It  should  be  emphasized  though  that  the  construction  of 
a  simulation  model  is  an  iterative  process.  The  LAN  model 
specified  in  this  thesis  can  be  considered  as  a  low-level 
first  generation  model  which  allows  for  future  growth  by 
proceeding  to  a  more  complex  and  sophisticated  level  in 
future  generation  models. 
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